From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Release process (was Re: Move to a cadence release model?) Date: Wed, 11 Nov 2015 17:43:26 +0200 Message-ID: <831tbwlext.fsf@gnu.org> References: <8337wdn6uu.fsf@gnu.org> <86611975jo.fsf_-_@stephe-leake.org> <838u65kxly.fsf@gnu.org> <86mvuk4xxd.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447256856 11403 80.91.229.3 (11 Nov 2015 15:47:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 15:47:36 +0000 (UTC) Cc: emacs-devel@gnu.org, john@yates-sheets.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 16:47:27 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZwXcM-0002Up-R4 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 16:47:26 +0100 Original-Received: from localhost ([::1]:41368 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXcM-0000QP-5u for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 10:47:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXaQ-0007jd-RN for emacs-devel@gnu.org; Wed, 11 Nov 2015 10:47:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwXYh-0000Sf-HS for emacs-devel@gnu.org; Wed, 11 Nov 2015 10:45:26 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:59408) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwXYh-0000SH-8n for emacs-devel@gnu.org; Wed, 11 Nov 2015 10:43:39 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NXN00400Q3QEA00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 11 Nov 2015 17:43:30 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXN004UFQCF9A40@a-mtaout20.012.net.il>; Wed, 11 Nov 2015 17:43:27 +0200 (IST) In-reply-to: <86mvuk4xxd.fsf@stephe-leake.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194074 Archived-At: > From: Stephen Leake > Cc: john@yates-sheets.org, emacs-devel@gnu.org > Date: Wed, 11 Nov 2015 04:45:18 -0600 > > >> From: Stephen Leake > > >> Which is precisely why we have a feature freeze phase; it enforces this > >> desire. > > > > We cannot enforce it. > > Well, the feature freeze encourages developers to work on the release > more than a non-feature freeze model does. At least, it works that way > for me. Alternatively, someone else could simply take a break from working on Emacs until the freeze is over. > >> I know I would be _very_ tempted to ignore the release branch, to keep > >> working on my latest Cool Feature instead. > >> > >> If I know I have to wait for a release before I can merge to master > >> again, I'll work on the release as much as I can. > > > > These considerations will become valid only when we have enough > > developers paying attention to bugs that are reported. (That includes > > you, Stephen, btw.) (Upon re-reading, I apologize for being so blunt. It just feels too lonely there, at times.) > Yes. I don't scan the bug tool for bugs that I might be able to work on; > sometimes it seems I should. For now, I rely on someone interested in > the bug emailing me if they think I could help. I don't thibk this will work efficiently. > Is there a way to get an email for every new bug? Yes, subscribe to bug-gnu-Emacs mailing list. > I'm curious how much traffic that would be. You can see that in the archives. About 30 messages per day on the average, maybe. > During the last feature freeze, there were reminders on this list of the > bugs that were deemed release-critical. That's the last resort. There are gobs of bugs that don't block anything, and some of them are left alone for far too long. Even a prompt response that just says the bug was reproduced (or not), and ideally also with results of some initial investigation and/or request from the OP to provide more details or try something -- even this would be progress. And then there are small patches submitted there -- review and comment will be appreciated. Patches that are no-brainers, e.g., fixing a typo or some other obvious mistake, should be pushed if there are no comments after a week, say. > There may be other release-critical bugs that I can usefully work on. The problem IMO is not the release-critical bugs, it's all the rest. > I don't have statistics on how well the feature-freeze model works in > getting release-critical bugs fixed. It doesn't work at all. Release-critical bugs normally appear near the end of the pretest. Or at least they become important only then. By contrast, I'm not talking about bug fixing during the pretest, I'm talking about routine attention to the reported bugs.