From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: 21.2.90 pretest, 21.3, 21.4... Date: Tue, 05 Nov 2002 15:37:16 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211052037.gA5KbGR30714@rum.cs.yale.edu> References: <200211051839.gA5IdeN29722@rum.cs.yale.edu> <2950-Tue05Nov2002221725+0200-eliz@is.elta.co.il> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036530231 32625 80.91.224.249 (5 Nov 2002 21:03:51 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2002 21:03:51 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 189Aqz-0008Rh-00 for ; Tue, 05 Nov 2002 22:03:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 189AzA-0005Rp-00 for ; Tue, 05 Nov 2002 22:11:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 189AVM-0004rF-00; Tue, 05 Nov 2002 15:40:56 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189ARw-00041V-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 15:37:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189ARs-00040v-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 15:37:23 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 189ARs-00040r-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 15:37:20 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gA5KbGR30714; Tue, 5 Nov 2002 15:37:16 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: "Eli Zaretskii" Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9149 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9149 > > > IMHO, it doesn't make sense to feature-freeze the trunk unless we decide > > > not to release from the branch anymore. > > > > Why is that ? > > Even if we feature freeze it now, 21.4 will not be out before the end > > of 2003. I.e. long after 21.3. > > If you suggest to have two pretests running in parallel, I don't think > we can manage that with the available resources. feature-freeze != pretest. > > Rather I suggest that we don't have the manpower to have several > > active branches at the same time and do a good job with it. > > So if we wanted 21.2 to be a really good bug-fix release, we should > > have concentrated on bug-fixing while keeping it on the trunk so > > that everyone was working on bug-fixing exclusively. > > That'd be a step back to the previous development model, I think: > there was no branches, and development would actually stop while bugs > in a major release were fixed. It's possible to argue that we should > go back, but I thought the current model was supposed to make the > development faster and releases more frequent. Quite right. I think we should go back, unless we find enough people to volunteer. Although, now that I think about it again, I disagree with what I said before. I can't remember precisely enough what stage we were at when we started 21.2. So maybe the way we did 21.2 was OK, because 21.1 was major enough to justify a bug-fix-only release. But for 21.3, if it had been forked from the trunk rather than from RC could have been overall just as stable as 21.3 is. So I just think that all releases should be forked from the trunk rather than from a previous release branch. I.e. each release branch leads to one and only one release (barring emacs-19.34 and 19.34a kind of things, obviously). That might have made the 21.3 debugging&pretest a bit longer but would have made it more useful (we would have found some bugs which are still right now in the trunk, unbeknownst to us) and people would able to use some of the new features that were implemented two years ago. The above reasoning might also apply for 21.2, but I can't remember enough to be sure. > > > That is, do you suggest to skip branch releases because they are not more > > > stable _in_principle_, or just because we are too inept to make them > > > significantly more stable? > > > > They are only more stable in cases where there really is a significant > > new feature that destabilizes the code base. E.g. the new redisplay in > > Emacs-21, or a unicode-based internal encoding for Emacs-22. > > I think this is too extreme: many changes on the trunk have enough > potential to destabilize the code. So we obviously disagree. > > Look, I'm not against faster development, I just think that with the > current manpower and without a full-time head maintainer we won't be > able to do much better. We could improve the development on the trunk > or on the branch, but not both. When I was working on the branch > releases, I felt that the trunk is favored more than the branch, which > IMHO is one reason why the bug-fix releases didn't happen frequently > enough. (My hope was that we could release 21.2 a month or two after > 21.1 and 21.3 a month after 21.2.) Complete agreement. I just think it's more important to concentrate our manpower on the trunk than on the branch. Stefan