From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Reordering etc/NEWS Date: Wed, 09 May 2007 15:25:35 -0700 Message-ID: <87sla5iqhs.fsf@red-bean.com> References: <2wmz0iriyj.fsf@fencepost.gnu.org> <87fy65k6eh.fsf@red-bean.com> <853b25lk43.fsf@lola.goethe.zz> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1178749551 5758 80.91.229.12 (9 May 2007 22:25:51 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 9 May 2007 22:25:51 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, rms@gnu.org, "Kim F. Storm" To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 10 00:25:50 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HlubS-0002oG-Ah for ged-emacs-devel@m.gmane.org; Thu, 10 May 2007 00:25:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hluig-00066r-VP for ged-emacs-devel@m.gmane.org; Wed, 09 May 2007 18:33:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hluid-000637-6J for emacs-devel@gnu.org; Wed, 09 May 2007 18:33:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hluic-00062v-5P for emacs-devel@gnu.org; Wed, 09 May 2007 18:33:10 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hluib-00062s-WD for emacs-devel@gnu.org; Wed, 09 May 2007 18:33:10 -0400 Original-Received: from sanpietro.red-bean.com ([66.146.193.61]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HlubK-00032g-K9; Wed, 09 May 2007 18:25:38 -0400 Original-Received: from localhost ([127.0.0.1]:41894 ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.63) (envelope-from ) id 1HlubI-00087a-Ez; Wed, 09 May 2007 17:25:36 -0500 In-Reply-To: <853b25lk43.fsf@lola.goethe.zz> (David Kastrup's message of "Thu\, 10 May 2007 00\:15\:08 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.98 (gnu/linux) X-detected-kernel: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:70719 Archived-At: David Kastrup writes: > The one posting you have missed of importance is the one where Richard > asked for volunteers that would consider taking over maintenance of > Emacs once the release is out of the door. I have no idea what list > of candidates, if any, has resulted from that. I also have no idea > what candidates might have been struck from the list as the result of > their way of voicing their concerns about the current process. I > certainly hope the list is not empty. Thanks; sorry I missed that one, and I can see how it might make a difference (although it's worth questioning the need to have a single maintainer at all -- many projects don't, and do just fine). > Richard has just announced that he plans on releasing Emacs 22.1 from > the EMACS_BASE_22 branch. It is not clear to me what should right now > happen on the trunk, though: should the branch merges of multitty and > emacs-unicode-2 commence now, or later? I think merges of complex development branches can be handled incrementally by using bidirectional merging: 1) Repeatedly merge trunk into the branch, so the branch isn't generally much out-of-date (w.r.t. recent trunk changes). 2) Get some developers to agree to run the branch for a while, to test for obvious showstoppers. 3) One day, when the new work on the branch is done, merge it into trunk. It'll already contain everything trunk contains, so the only new material will be the branch work, and that will be well-tested. IOW, trunk always gets new changes, except when they might destabilize trunk to the point of unusability, in which case a branch is used temporarily to stabilize them -- after which they go to trunk. So regarding your original question: what state of testedness are the multitty and emacs-unicode-2 branches in, and how far out of date w.r.t. trunk are they? -Karl