From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: Next release Date: Sat, 03 May 2008 23:58:57 -0700 Message-ID: <200805040658.m446wvLH012958@sallyv1.ics.uci.edu> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1209884489 8441 80.91.229.12 (4 May 2008 07:01:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 4 May 2008 07:01:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 04 09:02:03 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 1JsYEP-0003sf-Et for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 09:01:57 +0200 Original-Received: from localhost ([127.0.0.1]:34839 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsYDh-0007Xk-UE for ged-emacs-devel@m.gmane.org; Sun, 04 May 2008 03:01:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JsYDc-0007Ul-Fp for emacs-devel@gnu.org; Sun, 04 May 2008 03:01:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JsYDb-0007TQ-Hu for emacs-devel@gnu.org; Sun, 04 May 2008 03:01:08 -0400 Original-Received: from [199.232.76.173] (port=48704 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JsYDb-0007Sw-9r for emacs-devel@gnu.org; Sun, 04 May 2008 03:01:07 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JsYDU-0005tm-Vf; Sun, 04 May 2008 03:01:01 -0400 Original-Received: from sallyv1.ics.uci.edu ([128.195.1.109]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JsYDT-0006nD-SJ; Sun, 04 May 2008 03:01:00 -0400 X-ICS-MailScanner-Watermark: 1210489138.42984@N6oV5l4qgPSbEdLDIxGu7w Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv1.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id m446wvLH012958; Sat, 3 May 2008 23:58:57 -0700 (PDT) Original-Lines: 196 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by mx20.gnu.org: Solaris 10 (beta) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) 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:96424 Archived-At: Eli Zaretskii writes: > > 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. Can you please first get all the background before intervening? Doing that is absolutely not helpful. I am very disappointed, I didn't expect this from you Eli. > All that Mitsuharu asks for is higher level of quality for the code > committed to CVS. I think it's a reasonable request. Except that is not what is going on. > 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. This is totally unrelated to the problem at hand. > 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. Again, you have completely misunderstood the issue, ths has absolutely no relation with what is happening here. Now, I really don't like doing this, but I feel that I really need to get my name cleared here, so let's go back to what has actually happened. In the discussion about next release: Chong Yidong writes: > If all goes well, the Emacs 23 freeze will begin sometime in late June, > depending on how long Handa's font-backend branch and (hopefully) ECB > take to merge into the trunk. From that point, I'm hoping for around > six months of testing until the 23.1 release. With this time frame, I > don't think we will release 22.3 , unless a security hole appears that > we need to fix. > > In other words, go ahead and check in minor fixed to the branch if you > like, but it's not necessary. Major fixes definitely should *not* go ^^^^^^^^^^^^^^ > into the branch, since there will be no time to do extensive testing if > a security release is needed. Me: Does the above apply to all platforms? Looking at src/ChangeLog there are pages after pages of changes for the Mac, which don't look at all like minor changes... Anything wrong with this? It's just a discussion on the policy for the 22 branch. Now comes the reply from Yamamoto Mitsuharu: > You're seeing the changes that have been accumulated for a > relatively long period because I restricted the changes between > 22.1 and 22.2 to strict bug fixes. This was corrected in a subsequent email: > Correction: not "between 22.1 and 22.2", but "between 22.0.90 and > 22.2". That's why the recent changes include those as of > before-merge-multi-tty-to-trunk. Continuation from the first Yamamoto Mitsuharu email: > > Don't worry. They don't break the Carbon port of Emacs 22 unlike > the minimally-tested multi-tty support you've done for the Carbon > port of Emacs 23. Seriously? Where did this attack come from? We where talking about the release policy for the 22 branch. Now let's see what has been going on with multi-tty. The author of multi-tty has stopped contributing to emacs before the branch was merged, so I took up the task to get it merged. I had to go through all the red tape to get RMS to approve the merger, like rewrite ChangeLogs and reimplement setting environment variables, and fixed many many bugs after the merger. I also did a significant chunk of getting the Windows port to work (the rest of the work was done by Jason). Logs are all available, look on the multi-tty branch in CVS. Only GNU/Linux and Windows where mentioned as show stoppers for the merge. But I thought I could help to get the merge going on the Mac too. So I did that, and sent an email about it to the mac maintainer, Yamamoto Mitsuharu, and he replied: >>>>> On Mon, 21 May 2007 08:25:27 -0700, Dan Nicolaescu said: > YAMAMOTO-san, > I have ported the emacs multi-tty branch to MacOS. It seems to work > fine, but I have only done minimal testing. (I did this in a few > hours on a borrowed machine that I had to return). > I have tried to keep the changes to a minimum to minimize merging > effort between the branch and trunk. (for example mac-win.el should > be re-indented after the branch is merged to the trunk, a lot of > global forms are now in a function). > If you have a chance to test the branch more that would be very > good. I don't have access to a MacOS machine, so if you find > problems, I can only help in a limited way. Thanks for your effort. But as I already said in http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00310.html, I'm not interested in developing/maintaining the Carbon port for Emacs 23. I have some pending changes locally, and they are kept for Emacs 22.x after the release. I guess they don't interfere with your changes for multi-tty. ---- "Minimal testing" above meant that "emacs -nw" worked and the GUI started and emacsclient and emacsclient -t could connect to it. So this states pretty clearly that the Mac Carbon port was going to be unmaintained. I have fixed a few more bugs after that, and tried to help quite a few users to get it working. I am sure I could have finished the work, although it would have meant that I needed to get access to a Mac machine again. AFAIK there's a just a problem with the input being very slow. But given that the maintainer abandoned the platform, why would any reasonable person spend more time trying to develop it? So I didn't. Note that this work was all on the multi-tty branch, not in CVS HEAD. So if Yamamoto Mitsuharu would have actually cared about this code, he could have said something a year ago when this was happening, asked for the code to be changed/fixed/removed or even blocked the merger. Nothing of the sort was done at the time. For good measure Carbon is unsupported now in CVS HEAD because it is unmaintained and nobody has done any actual work to get it going. Again, reports are And yes, I do stand by the work I did then. It was incomplete (due to circumstances explained in detail a few times on the list), but it was the major chunk needed to get the Carbon port working. I did not even compile before that. And yes, in retrospect, even trying to help with this work was a great mistake and waste of time and energy. And no, someone that has not helped that effort in any way (i.e. Yamamoto Mitsuharu), despite being the most qualified person for the job, has absolutely no standing to send nastygrams about it today. I am puzzled about the motivation to even bring this up today in an unrelated discussion. Yamamoto Mitsuharu has been pestering the list about multi-tty (with no clear explanation of the reason for this fixation) since multi-tty was merged. It is indeed strange, he does not plan to work on it, but he still has a problem with it. Just search for his name and "multi-tty". This is what I called "whining". Thank you for your attention. Now can we please stop this? It is absolutely annoying, unproductive and a complete waste of time.