From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: unicode-2 and multitty Date: Mon, 07 May 2007 12:09:33 +0200 Message-ID: <86bqgxymg2.fsf@lola.quinscape.zz> References: <87647ooxwm.fsf@zip.com.au> <462CC030.8030203@gmail.com> <87mz0y8vyk.fsf@zip.com.au> <86vef90x54.fsf_-_@lola.quinscape.zz> <463AFFC9.90307@gnu.org> <86r6pw28w0.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1178532593 10928 80.91.229.12 (7 May 2007 10:09:53 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 7 May 2007 10:09:53 +0000 (UTC) Cc: Jason Rumney , Stefan Monnier , emacs-devel@gnu.org To: storm@cua.dk (Kim F. Storm) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 07 12:09:51 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 1Hl0AA-0004fG-Py for ged-emacs-devel@m.gmane.org; Mon, 07 May 2007 12:09:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hl0H6-0000MG-MN for ged-emacs-devel@m.gmane.org; Mon, 07 May 2007 06:17:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hl0H2-0000Lq-Sq for emacs-devel@gnu.org; Mon, 07 May 2007 06:16:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hl0H1-0000Ld-4W for emacs-devel@gnu.org; Mon, 07 May 2007 06:16:56 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hl0H0-0000La-Su for emacs-devel@gnu.org; Mon, 07 May 2007 06:16:54 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Hl0A0-0001se-ST for emacs-devel@gnu.org; Mon, 07 May 2007 06:09:42 -0400 Original-Received: from quinscape.de (pd95b0fdb.dip0.t-ipconnect.de [217.91.15.219]) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id MAA14200 for ; Mon, 7 May 2007 12:09:31 +0200 X-Delivered-To: Original-Received: (qmail 30221 invoked from network); 7 May 2007 10:09:34 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 7 May 2007 10:09:34 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id 1AF808F95C; Mon, 7 May 2007 12:09:34 +0200 (CEST) In-Reply-To: (Kim F. Storm's message of "Mon\, 07 May 2007 11\:55\:27 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 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:70614 Archived-At: storm@cua.dk (Kim F. Storm) writes: > Stefan Monnier writes: > >>> Maybe you don't need to import the multitty changes as a branch >>> in CVS. I suppose that the changes can be committed directly on the >>> TRUNK as a (big) set of changes. >> >> I might be sufficient, but I think it might also be worthwhile to first >> commit it on a separate branch and then try and merge it. >> It just seems conceptually cleaner, leaving a clear and recognizable tra= ce >> of the branch before it was merged. > > For that, you can just put a "BEFORE_MULTITTY_MERGE" tag on the trunk. The disadvantage is that while the merge is in progress, the trunk will not be usable. However, a) unless I am mistaken, K=E1roly's version of the multitty code _is_ essentially merged with the trunk already (though trunk moves onward). The merge will just be concerned with stuff checked in since the last synch. b) if trunk does not work right away, this would be a strong incentive for people to fix this. So we basically need two things to go ahead a) K=E1roly's opinion of the state of his archive, and his possible resources/involvement for putting the stuff into branch or trunk. b) the "go ahead" from Richard. While Richard has been looking for a maintainer for 23.x, it would appear to me that actually commencing the merge would not require a previous appointment of a different maintainer. --=20 David Kastrup