From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Next release Date: Sun, 04 May 2008 07:21:29 +0300 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> <200805040206.m4426oct013714@sallyv1.ics.uci.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1209874986 22066 80.91.229.12 (4 May 2008 04:23:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2008 04:23:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 04 06:23:41 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 1JsVlE-0005Y4-9V for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 06:23:40 +0200 Original-Received: from localhost ([127.0.0.1]:38628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsVkW-0000H0-Ou for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 00:22:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JsVkS-0000EB-6D for emacs-devel@gnu.org; Sun, 04 May 2008 00:22:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JsVkR-0000DZ-OM for emacs-devel@gnu.org; Sun, 04 May 2008 00:22:51 -0400 Original-Received: from [199.232.76.173] (port=35979 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsVkR-0000DW-IP for emacs-devel@gnu.org; Sun, 04 May 2008 00:22:51 -0400 Original-Received: from mtaout5.012.net.il ([84.95.2.13]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JsVkR-0003xY-Da for emacs-devel@gnu.org; Sun, 04 May 2008 00:22:51 -0400 Original-Received: from HOME-C4E4A596F7 ([84.229.228.217]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0K0B00CGPU3M41Q1@i_mtaout5.012.net.il> for emacs-devel@gnu.org; Sun, 04 May 2008 07:35:47 +0300 (IDT) In-reply-to: <200805040206.m4426oct013714@sallyv1.ics.uci.edu> X-012-Sender: halo1@inter.net.il X-detected-kernel: by monty-python.gnu.org: Solaris 9.1 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:96420 Archived-At: > From: Dan Nicolaescu > Date: Sat, 03 May 2008 19:06:50 -0700 > Cc: Glenn Morris , Chong Yidong , > Nick Roberts , emacs-devel@gnu.org > > > It seemed to me that you just superficially removed compilation > > errors, with minimal test (you said that it was minimally-tested). > > Just like you literally replaced `next-line' with `forward-line' to > > remove byte-compiler warnings without considering their meanings. > > Thank you yet again for your graciousness! Again given statements like: > > "As for Mac, I'm planning to quit the development of the Carbon port > for Emacs 23, as the Cocoa/GNUstep port will replace it on that > version. So, personally I don't care if multitty is incompatible with > the current Carbon code as long as it is not for Emacs 22.x (x > 1)." > > and the excellent job at whining, moaning and dissing the multi-tty > effort, coupled with no code/documentation or any other type of positive > contribution should be appreciated as a great upper hand that can be > used to disparage volunteer work by other people. Marvelous! Dan, please stop this. All that Mitsuharu asks for is higher level of quality for the code committed to CVS. I think it's a reasonable request. You seem to assert that when faced with changes which could potentially break other platforms, there's only two possible alternatives: either live with the breakage or don't commit the code at all. But in fact, there's a 3rd alternative: learn enough about those other platforms to make the code right on them as well. There's even a 4th alternative: make the new code be conditionally compiled only on platforms you understand and can test. All of those are IMO better than breakage. So I don't understand why you reject such suggestions as ``whining''. Certainly, being the one who works on the code imposes some responsibility on you.