From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Release procedure. Date: Sun, 06 May 2007 20:18:23 -0700 Message-ID: <87fy69wccg.fsf@red-bean.com> References: <87lkg23fbn.fsf@red-bean.com> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1178507914 10163 80.91.229.12 (7 May 2007 03:18:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 May 2007 03:18:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 07 05:18:33 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hktk8-0004B7-8H for ged-emacs-devel@m.gmane.org; Mon, 07 May 2007 05:18:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hktr3-0001vV-6r for ged-emacs-devel@m.gmane.org; Sun, 06 May 2007 23:25:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hktqz-0001qC-JA for emacs-devel@gnu.org; Sun, 06 May 2007 23:25:37 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hktqx-0001n5-Na for emacs-devel@gnu.org; Sun, 06 May 2007 23:25:37 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hktqx-0001mi-JR for emacs-devel@gnu.org; Sun, 06 May 2007 23:25:35 -0400 Original-Received: from sanpietro.red-bean.com ([66.146.193.61]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hktk1-0001M6-IE for emacs-devel@gnu.org; Sun, 06 May 2007 23:18:25 -0400 Original-Received: from localhost ([127.0.0.1]:53881 ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.63) (envelope-from ) id 1Hktk0-0001xT-8p; Sun, 06 May 2007 22:18:24 -0500 In-Reply-To: (Stefan Monnier's message of "Sun\, 06 May 2007 22\:25\:50 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux) X-detected-kernel: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:70609 Archived-At: Stefan Monnier writes: >> I've long been baffled that trunk work is affected by the fact that a >> release is under way. > > The reason is very simple: because of a lack of resources, we can't spread > half the resources working on a "new trunk" with the half working on > bug-fixing on a release branch. So we first declare a freeze, then do > bug-fixing on the trunk (during which time, development is significantly > slowed down), and only when the amount of bug-fixing left is expected to be > sufficiently low, do we finally branch so as to allow people to start > hacking again without affecting negatively the time of the release. > > It's a delicate balancing exercise to motivate people to do bug-fixing and > other release-preparation work without frustrating them away. Thanks for the explanation. I think, though, that this is based on a fallacy about fixed resources. It might even be *causing* a lack of resources. If each developer were going to do X amount of work no matter what, and that work could either be "new trunk" or release work, then this method would make sense. But in practice, many of us just stop doing anything at all during the release process. On the other hand, if there were a release branch, those who were going to do release bug-fixing work anyway could do it just as well on the release branch, while others are active as usual on trunk. (In practice, the same people often do both, but the difference is that they could choose what to do when, and thereby do more.) Of course, I understand there's some overhead: in such a system, when you find a bug on the release branch, the usual procedure is to fix it on trunk, then port the fix over to the release branch. Ongoing trunk work can sometimes interfere with that porting, so the system isn't completely costless. But other projects I work on use it, and my impression (based on a lot of experience, at this point) is that it results in a) more development activity overall, and b) not noticeably less release work. Whereas right now, when Emacs trunk is frozen, I am frozen (except when a bug comes up in a package I maintain, of course). I don't have time to work on the release, though I occasionally have time to make contributions that aren't urgent enough to go into a releasable line. Until we finish the release, those contributions are held up. It seems I'm not the only person in this situation. It's not like fungible resources being divvied up among different tasks -- rather, it's contributions being delayed, for IMHO doubtful gain. Thanks, -Karl