From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Nick Roberts Newsgroups: gmane.emacs.devel Subject: Re: It is time for a feature freeze (it is NOW or never). Date: Sun, 2 May 2004 21:14:06 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <16533.22158.252815.200578@nick.uklinux.net> References: <87hdvux5uz.fsf@orebokech.com> <87lll6v514.fsf@orebokech.com> <200404100109.KAA03816@etlken.m17n.org> <20040501232151.GA10382@fencepost> <16533.14869.127534.911979@nick.uklinux.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1083529132 6517 80.91.224.253 (2 May 2004 20:18:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 May 2004 20:18:52 +0000 (UTC) Cc: rms@gnu.org, Kenichi Handa , emacs-devel@gnu.org, Stefan Monnier , "Kim F. Storm" , Miles Bader Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun May 02 22:18:42 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKNQA-0004GO-00 for ; Sun, 02 May 2004 22:18:42 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKNQA-0007mu-00 for ; Sun, 02 May 2004 22:18:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKNNP-0007Ah-EB for emacs-devel@quimby.gnus.org; Sun, 02 May 2004 16:15:51 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKNMj-00078P-OV for emacs-devel@gnu.org; Sun, 02 May 2004 16:15:09 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKNMC-0006S1-7P for emacs-devel@gnu.org; Sun, 02 May 2004 16:15:08 -0400 Original-Received: from [194.247.51.171] (helo=nick.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKNLR-00054G-3p; Sun, 02 May 2004 16:13:49 -0400 Original-Received: by nick.uklinux.net (Postfix, from userid 501) id CFB9875FDE; Sun, 2 May 2004 21:14:06 +0100 (BST) Original-To: David Kastrup In-Reply-To: X-Mailer: VM 6.97 under Emacs 21.2.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22563 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22563 > > Otherwise new features will have no place to go and will quite > > likely get bundled in with bug-fixes. > > New features can go into branches if really necessary. By new features, I just mean patches that might break functionality. They might be too small to justify a separate branch. > > Also, from the mailing list archives, I see that a year elapsed > > between the first pretest and the release of Emacs 21.1. So I would > > like to see a target date for the release so that the "freeze" > > doesn't drag on indefinitely. > > Nope. There is no point in releasing it before it is ready. And > there is no sense in delaying further once it is ready. Well, Confucius might say something like that. If there was a nominal date, developers like Kai, could make a judgement as to whether or not there was enough time to merge new features of Tramp. > And there is > no point in telling a lot of voluntary that they have to deliver on a > certain date or lose their non-job. It would just be something to aim for. I don't remember talking about penalty clauses. Currently, for all I know, features of GDB needed by gdb-ui.el may be obsolete before the next Emacs release. Nick