From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel,gmane.emacs.multi-tty Subject: Re: Merging multitty Date: Fri, 11 May 2007 10:20:30 +0100 Message-ID: <4644355E.7070004@gnu.org> References: <2wmz0iriyj.fsf@fencepost.gnu.org> <87fy65k6eh.fsf@red-bean.com> <853b25lk43.fsf@lola.goethe.zz> <86bqgr3g1h.fsf_-_@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1178876131 23350 80.91.229.12 (11 May 2007 09:35:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 May 2007 09:35:31 +0000 (UTC) Cc: multi-tty@fnord.hu, emacs-devel@gnu.org, karoly@lorentey.hu, rms@gnu.org, Kenichi Handa To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 11 11:35:30 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 1HmRX4-0000Fo-MW for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 11:35:26 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmReR-0001lP-IT for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 05:43:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HmRbl-0000tK-Pt for emacs-devel@gnu.org; Fri, 11 May 2007 05:40:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HmRbk-0000st-IR for emacs-devel@gnu.org; Fri, 11 May 2007 05:40:17 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmRbj-0000sV-Am for emacs-devel@gnu.org; Fri, 11 May 2007 05:40:15 -0400 Original-Received: from outmail1.freedom2surf.net ([194.106.33.237]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HmRUH-0008O5-IW; Fri, 11 May 2007 05:32:33 -0400 Original-Received: from [127.0.0.1] (i-83-67-23-108.freedom2surf.net [83.67.23.108]) by outmail1.freedom2surf.net (Postfix) with ESMTP id 6FBA16F1D5; Fri, 11 May 2007 10:20:33 +0100 (BST) User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) In-Reply-To: <86bqgr3g1h.fsf_-_@lola.quinscape.zz> 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:70794 gmane.emacs.multi-tty:675 Archived-At: David Kastrup wrote: > However, I think we more or less agreed that it would be more prudent > to merge the multitty stuff first and follow up with the Unicode > branch, since that would minimize the merge work on multitty where we > have less active expertise to rely on. > I don't recall ever agreeing this, although you have asserted so numerous times over the last few weeks. The merge between multitty and unicode will be the same, whichever order it is done in. The simple fact is that emacs-unicode-2 is ready to go onto the trunk, and the multitty is not due to issues mentioned in the README on Karoly's website. > In either case, a merge into trunk is quite a bit of work. > I think in both cases, the branches are well synched with trunk already, so there should be very little work in moving either one of the branches to the trunk (though in the case of multitty it would break Emacs on some platforms). The work comes when the non-merged branch is next synched to the trunk. The conflicts will be the same whichever direction the merge happens in, so I don't see any compelling reason to hasten the multitty merge to trunk (but it should be checked in on a branch ASAP so the problems mentioned above can be worked on by someone who is familiar with the platforms affected). Your point that Karoly is not going to be available for much longer is a point against merging into trunk quickly IMHO. Either someone else will step forward to maintain that code, in which case it doesn't matter if the merge to trunk happens later, or noone wants to maintain the multitty code, in which case merging into trunk would be a mistake.