From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: It is time for a feature freeze (it is NOW or never). Date: 02 May 2004 20:43:17 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: 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 X-Trace: sea.gmane.org 1083523481 28322 80.91.224.253 (2 May 2004 18:44:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 2 May 2004 18:44:41 +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 20:44:32 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 1BKLx2-00007O-00 for ; Sun, 02 May 2004 20:44:32 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKLx2-0006L4-00 for ; Sun, 02 May 2004 20:44:32 +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 1BKLwj-0002MB-Px for emacs-devel@quimby.gnus.org; Sun, 02 May 2004 14:44:13 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKLwd-0002Kl-JH for emacs-devel@gnu.org; Sun, 02 May 2004 14:44:07 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKLw7-000279-E9 for emacs-devel@gnu.org; Sun, 02 May 2004 14:44:06 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKLw6-00026y-Uf for emacs-devel@gnu.org; Sun, 02 May 2004 14:43:34 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BKLvx-0006if-De; Sun, 02 May 2004 14:43:28 -0400 Original-To: Nick Roberts In-Reply-To: <16533.14869.127534.911979@nick.uklinux.net> Original-Lines: 45 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:22547 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22547 Nick Roberts writes: > > >> > > So when do we declare "feature freeze" ? May 1st ? > > >> > May 1st sounds very good to me, > > >> Too good to be true ? > > > Um, as you seem to be adding many of the new features these > > > days, why don't you tell us? > > > > As a perpertrator of "last minute feature addition", I can't > > complain. But in any case I think people should from now on > > concentrate on bug-fixing (which might include some > > interface-changes, admittedly). > > IMHO, any feature freeze is only meaningful if it is accompanied by > a branch. No. > 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. And we already _have_ some things like lexical, bidi, multi-tty, unicode and so on in branches. So it is not that this is a novelty. But developers should get their head wrapped around getting Emacs into releasable state rather than bothering with new features now, if possible. > 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. 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. > Well, one can only hope. And work. Proofreading the manual is something that needs not be restricted to core developers. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum