From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: 21.2.90 pretest, 21.3, 21.4... Date: Tue, 05 Nov 2002 22:17:25 +0300 Sender: emacs-devel-admin@gnu.org Message-ID: <2950-Tue05Nov2002221725+0200-eliz@is.elta.co.il> References: <200211051839.gA5IdeN29722@rum.cs.yale.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1036527777 20463 80.91.224.249 (5 Nov 2002 20:22:57 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2002 20:22:57 +0000 (UTC) Cc: 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 189ADw-0005Jt-00 for ; Tue, 05 Nov 2002 21:22:56 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 189AM6-0004X0-00 for ; Tue, 05 Nov 2002 21:31:22 +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 189ABT-0000KB-00; Tue, 05 Nov 2002 15:20:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189A7e-0007wa-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 15:16:26 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189A7b-0007wJ-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 15:16:26 -0500 Original-Received: from freya.inter.net.il ([192.114.186.14]) by monty-python.gnu.org with esmtp (Exim 4.10) id 189A7a-0007vx-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 15:16:23 -0500 Original-Received: from zaretsky (adsl-ayalon-pc-128-136.inter.net.il [213.8.128.136]) by freya.inter.net.il (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id BXT87842; Tue, 5 Nov 2002 22:16:17 +0200 (IST) Original-To: monnier+gnu/emacs@rum.cs.yale.edu X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <200211051839.gA5IdeN29722@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) 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:9144 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9144 > From: "Stefan Monnier" > Date: Tue, 05 Nov 2002 13:39:40 -0500 > > > > 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. > 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. > > > As Dave has explained the bug-fix release 21.3 will still be riddled > > > with bugs > > FWIW, I think ``riddled with bugs'' is a grave exaggeration. > > It all depends on what you consider as a bug, so I stand by my claim > that it will be riddled with bugs. My objection was to the ``riddled'' part, not to the ``bugs'' part. I don't think it's a fair description of the state of the code. > > 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.)