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: It is time for a feature freeze (it is NOW or never). Date: 08 Apr 2004 12:22:53 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87u0zufp7t.fsf-monnier+emacs@alfajor.local> References: <87eks0654s.fsf@sno.mundell.ukfsn.org> <87n06bp4ng.fsf@sno.mundell.ukfsn.org> <8765cwkejr.fsf@mail.jurta.org> <200404071157.UAA25094@etlken.m17n.org> <200404071312.WAA25268@etlken.m17n.org> <87zn9nqras.fsf@emacswiki.org> <200404080203.LAA26847@etlken.m17n.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081441946 8210 80.91.224.253 (8 Apr 2004 16:32:26 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 8 Apr 2004 16:32:26 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 08 18:32:16 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 1BBcRr-0006QL-00 for ; Thu, 08 Apr 2004 18:32:15 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BBcRr-0006tp-00 for ; Thu, 08 Apr 2004 18:32:15 +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 1BBcMF-0001Ik-Sl for emacs-devel@quimby.gnus.org; Thu, 08 Apr 2004 12:26:27 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BBcLe-00015J-JA for emacs-devel@gnu.org; Thu, 08 Apr 2004 12:25:50 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BBcKj-0000fB-E3 for emacs-devel@gnu.org; Thu, 08 Apr 2004 12:25:24 -0400 Original-Received: from [209.226.175.4] (helo=tomts16-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BBcIu-0008PD-1B; Thu, 08 Apr 2004 12:23:00 -0400 Original-Received: from alfajor ([67.71.119.143]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040408162254.CTEL11615.tomts16-srv.bellnexxia.net@alfajor>; Thu, 8 Apr 2004 12:22:54 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id B7050D73B5; Thu, 8 Apr 2004 12:22:53 -0400 (EDT) Original-To: Kenichi Handa In-Reply-To: <200404080203.LAA26847@etlken.m17n.org> Original-Lines: 56 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:21380 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21380 > (1) Release the current RC branch as 21.4. I don't consider it very useful, but if people want to spend their time on it I can't stop them. > (2) Feature freeze on HEAD. > (3) Merge HEAD into RC branch, and make it 21.4.50. > (4) Merge Unicode branch into HEAD, and make it 22.0.0. > (5) Start pretest of 21.5 based on RC. > (6) Release RC branch as 21.5. > ... > (7) Feature freeze on HEAD (i.e. Unicode version) > (8) Merge HEAD into RC branch, and make it 22.0.50. I'd offer a very slightly different schedule: (2) Feature freeze on the trunk NOW (3) Start pretest from the trunk (maybe after fixing known bugs, but there doesn't seem to be many of those, so it seems unnecessary). (4) When bug-fixing starts to slow down such that some developers feel bored, make a new RC branch and move the bug-fixing and pretesting there. Those people who are bored can start playing on the trunk again. (5a) Finish bug-fixing RC and finally Release. (5b) Merge unicode, multi-tty, and bidi (in this order, but quickly) to the trunk. Branches basically don't get any testing and waste too much of our energy with merging, so we should only keep them for code that's really unstable or that we don't know whether we'll ever include. E.g. if bidi only crashed when you set enable-bidi-display, then it's ready for inclusion. I'd also like to see the emacs-xft (anti-aliasing) merged in, but AFAIK it's not ready yet. (6) Almost immediately after that: goto number (2). Note that the plan above tries to reduce the amount of "parallel development" for two reasons: - we need to make sure people focus on fixing bugs during the pretest. - we don't have the manpower to work and test many branches at the same time, let alone keep them uptodate w.r.t the trunk. > Do you intend to skip (1)? Perhaps, that will be better > because we can avoid disappointing users who exepect new > features in the release of this long delay. Agreed. > I agree. But, I think bug-fixing work for 21.5 (or 21.4) > must be done on RC branch so that (4) can be done promptly > and we can have more users of Unicode version, which boosts > the release of 22.1. You have a point but I think we should only do it when the bug-fixing frenzy slows down (hopefully this will happen very quickly). But of course, as soon as the bugs left over are "none of your business", you'd better start merging rather than twiddle your thumbs. Stefan