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 13:39:40 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211051839.gA5IdeN29722@rum.cs.yale.edu> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036522712 28937 80.91.224.249 (5 Nov 2002 18:58:32 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 5 Nov 2002 18:58:32 +0000 (UTC) Cc: Stefan Monnier , 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 1898uE-0007Wb-00 for ; Tue, 05 Nov 2002 19:58:30 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18992N-0002Vg-00 for ; Tue, 05 Nov 2002 20:06:55 +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 1898qP-0006yU-00; Tue, 05 Nov 2002 13:54:33 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 1898cL-0004Ch-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 13:40:01 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 1898cD-00048d-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 13:39:57 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 1898cC-00047X-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 13:39:52 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gA5IdeN29722; Tue, 5 Nov 2002 13:39:40 -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:9139 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9139 > > I obviously agree since I called for a feature freeze a few weeks > > (months?) back already. > > 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. > > I also think that 21.2 should have been taken > > from the trunk rather than from the RC branch and same thing for 21.3. > > For 21.3, maybe. But for 21.2, I disagree. You effectively suggest to > eliminate bugfix releases, which I think would be wrong: users will have > no stable versions to rely upon. 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. > > 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. Most of them are not of the kind that segfault and most of them cannot be trivially fixed (i.e. fixed without a significant risk of introducing other bugs) so even if we spend another 10 years on "bugfixing" the RC branch, those bugs will still be there (even tho they might have already been fixed on the trunk months ago). > > Maybe it will be a bit > > more stable from one particular point of view because it doesn't use any > > new code that might introduce new bugs, but I'm definitely not convinced > > that it outweighs the number of unfixed non-trivial bugs. > > So do you really think that introduction of significant new features > doesn't destabilize Emacs? > > 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. The kinds of changes that took place on the trunk since Emacs-21.1 don't justify the burden of branch-releases. Stefan