Re: Next release

[Dan Nicolaescu]

Eli Zaretskii <address@hidden> writes:

  > > From: Dan Nicolaescu <address@hidden>
  > > Date: Sat, 03 May 2008 19:06:50 -0700
  > > Cc: Glenn Morris <address@hidden>, Chong Yidong <address@hidden>,
  > >   Nick Roberts <address@hidden>, address@hidden
  > > 
  > >   > 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 <address@hidden> 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 <address@hidden> 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.