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: 12 Apr 2004 00:33:40 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: 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> <87hdvux5uz.fsf@orebokech.com> <87lll6v514.fsf@orebokech.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1081744506 29831 80.91.224.253 (12 Apr 2004 04:35:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 12 Apr 2004 04:35:06 +0000 (UTC) Cc: romain@orebokech.com, emacs-devel@gnu.org, "Kim F. Storm" Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Mon Apr 12 06:34:58 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 1BCt9t-0004HN-00 for ; Mon, 12 Apr 2004 06:34:57 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BCt9s-0000Qn-00 for ; Mon, 12 Apr 2004 06:34:56 +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 1BCsCi-0002AP-5i for emacs-devel@quimby.gnus.org; Sun, 11 Apr 2004 23:33:48 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BCsCc-00029i-5S for emacs-devel@gnu.org; Sun, 11 Apr 2004 23:33:42 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BCsCa-00029M-Sv for emacs-devel@gnu.org; Sun, 11 Apr 2004 23:33:41 -0400 Original-Received: from [206.47.199.165] (helo=simmts7-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BCsCa-00029F-LV; Sun, 11 Apr 2004 23:33:40 -0400 Original-Received: from empanada.local ([67.70.165.72]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040412043337.ZKSJ13427.simmts7-srv.bellnexxia.net@empanada.local>; Mon, 12 Apr 2004 00:33:37 -0400 Original-Received: by empanada.local (Postfix, from userid 502) id D5C62153C33; Mon, 12 Apr 2004 00:33:40 -0400 (EDT) Original-To: rms@gnu.org In-Reply-To: Original-Lines: 24 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:21504 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21504 > I still think this is a bad idea -- it cannot be done without potentially > destabilizing the trunk which is currently in a very stable state, and > thus in a pretty unique state of "readiness for release". > We could urge all the pretesters to try out the unicode branch now. > That way we would get a picture of how far it is from readiness. What's the problem with releasing from the current trunk ASAP instead? Based on feedback from the few non-latin-only users I know, the trunk's unicode support is "good enough" and is a major improvement over Emacs-21.3. There's no shortage of improvements in the current trunk. Trying to merge the unicode branch before the next release would just delay the release of those improvements. Maybe it would end up releasing the unicode-branch a bit earlier, but I'm wondering why the unicode branch should be considered so much more important than all those other features. What concrete improvement does it bring to the user that's so valuable compared to all the rest that's already in the trunk (i.e. utf-8 CJK support, customizable fringes, many new packages, extra bundled manuals, the list in NEWS is already much too long). Stefan