From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Next release Date: Mon, 05 May 2008 08:52:25 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <18457.37369.262079.668907@kahikatea.snap.net.nz> <5jr6clncn8.fsf@fencepost.gnu.org> <87od7p22dw.fsf@stupidchicken.com> <200805021331.m42DVYVw016584@sallyv1.ics.uci.edu> <200805021610.m42GAhkE001271@sallyv1.ics.uci.edu> <200805040056.m440u3eS022727@sallyv1.ics.uci.edu> <874p9dn46h.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1209945171 4912 80.91.229.12 (4 May 2008 23:52:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2008 23:52:51 +0000 (UTC) Cc: Glenn Morris , Nick Roberts , Dan Nicolaescu , Stefan Monnier , emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 05 01:53:27 2008 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 1Jso1E-0004F2-CO for ged-emacs-devel@m.gmane.org; Mon, 05 May 2008 01:53:24 +0200 Original-Received: from localhost ([127.0.0.1]:52569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jso0W-0000r5-Ux for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 19:52:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jso0S-0000qb-PR for emacs-devel@gnu.org; Sun, 04 May 2008 19:52:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jso0R-0000qP-2e for emacs-devel@gnu.org; Sun, 04 May 2008 19:52:36 -0400 Original-Received: from [199.232.76.173] (port=59566 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jso0Q-0000qM-T3 for emacs-devel@gnu.org; Sun, 04 May 2008 19:52:34 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Jso0L-0003Vl-LH; Sun, 04 May 2008 19:52:30 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 975272C40; Mon, 5 May 2008 08:52:25 +0900 (JST) In-Reply-To: <874p9dn46h.fsf@stupidchicken.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/23.0.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-kernel: by monty-python.gnu.org: NetBSD 3.0 (DF) 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:96464 Archived-At: >>>>> On Sun, 04 May 2008 17:35:18 -0400, Chong Yidong said: >>> Yes, the merge had its share of problems, but the fact that >>> Lorentey wasn't around made it worse. But I don't know what >>> unrelated change you may be thinking about. >> >> Of course I can give concrete examples, which are Mac-specific. >> But the point is: I found some, then how can I assure there's no >> other? Rather, I would doubt the quality and reliability of the >> whole code from such kinds of changes. > Would you prefer that other Emacs developers avoid touching the > Carbon-specifics part of the Emacs tree, even if compilation breaks, > so that you are the only one responsible for changes to that part of > the code? That might be an acceptable arrangement, if that is what > you want. I'd appreciate changes from experts on other area, of course. I've been keeping the similarity of the Carbon-specific code not only for consistency with other platforms but also those who are familiar with other platforms but not with Carbon can easily find and touch the part for changes that are common to several platforms. (BTW, that's one difference from the Cocoa/GNUstep port.) The problem in the multi-tty case is, some changes that are totally unrelated to multi-tty were mixed into the multi-tty merger. If it was intentional, that's unfair. Otherwise, I doubt if the author did that job with enough understanding of the code. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp