From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Juanma Barranquero" Newsgroups: gmane.emacs.devel Subject: Re: Merging multitty Date: Fri, 11 May 2007 15:33:42 +0200 Message-ID: References: <87fy65k6eh.fsf@red-bean.com> <853b25lk43.fsf@lola.goethe.zz> <86bqgr3g1h.fsf_-_@lola.quinscape.zz> <4644355E.7070004@gnu.org> <867irf3cjo.fsf@lola.quinscape.zz> <86mz0b1p02.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1178890435 8547 80.91.229.12 (11 May 2007 13:33:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 11 May 2007 13:33:55 +0000 (UTC) Cc: emacs-devel@gnu.org, Kenichi Handa To: "David Kastrup" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 11 15:33:52 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 1HmVFj-0004q4-To for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 15:33:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmVNA-0003lK-0n for ged-emacs-devel@m.gmane.org; Fri, 11 May 2007 09:41:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HmVN7-0003lC-Ih for emacs-devel@gnu.org; Fri, 11 May 2007 09:41:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HmVN6-0003km-0e for emacs-devel@gnu.org; Fri, 11 May 2007 09:41:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HmVN5-0003kj-Uq for emacs-devel@gnu.org; Fri, 11 May 2007 09:41:23 -0400 Original-Received: from wx-out-0506.google.com ([66.249.82.228]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HmVFe-000817-Va for emacs-devel@gnu.org; Fri, 11 May 2007 09:33:43 -0400 Original-Received: by wx-out-0506.google.com with SMTP id s17so893102wxc for ; Fri, 11 May 2007 06:33:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=s3isgRhnTmR8xzm4pR9AsY6Px0ZDvxgNlu4G4NiMArQhq2BNI/RTaO8lV7c7wzhSaI2+/Xlnb1ResSgw4wqgUpU257nQzIcbqjeg5AAAqjltTXOOrIHWO2oI1E334QVnk/CPeru74kS+xd6hO5MkT0GFB7K2G5iLvYSkZMREAXo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C8xZr+ppCX7qF5lMYF0M4NXuLNE9mvFoekk1xV0rOO7FPq9AM3frAiZUUF0C5m9BRwT+W1/V7dmZXhwg8FklrBSYna5huQLZ56w8kWCIlOXrg8HGT45ScCdlvASvUEhhbXlD3niTi6rRDHk28OrSeLT8LldQkDGluRCGiqMT1r4= Original-Received: by 10.90.89.5 with SMTP id m5mr2890183agb.1178890422220; Fri, 11 May 2007 06:33:42 -0700 (PDT) Original-Received: by 10.90.103.8 with HTTP; Fri, 11 May 2007 06:33:42 -0700 (PDT) In-Reply-To: <86mz0b1p02.fsf@lola.quinscape.zz> Content-Disposition: inline X-detected-kernel: Linux 2.4-2.6 (Google crawlbot) 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:70809 Archived-At: On 5/11/07, David Kastrup wrote: > It certainly will be more convenient for people wanting to > _use_ the trunk as opposed to _work_ on it. No. It will be more convenient for people wanting to _work_ on the trunk on things _other_ than the multitty support. > I am not convinced that we will make speedy progress to Emacs 23 if we > insist on maintaining this state. There's a difference between breaking the trunk every now and then, with the understanding that the issues will be fixed ASAP, and breaking it and saying "here, if you want to use it, start by fixing it". In particular, the multitty branch is said not to work on Windows; and Emacs Windows developers are scarce. What if none of us has the time, knowledge or inclination to fix the multitty code soon? Saying "use a release branch, then" is a non-answer. > The second variant makes separate sense of its own mainly if one > _delays_ merging the multitty branch until it has stabilized on all > platforms. Which is a fine idea by itself. > I don't see that happening by magic. Either there is people willing to fix the problems in the multitty branch, and then a branch is fine, or there is not, and then forcing it on the trunk it's not going to help much (if anything, it'll diminish some people's enthusiasm). Juanma