Re: Merging multitty

[Jason Rumney]

David Kastrup wrote:
> I think we more or less agreed (modulo my possibly biased
> recollections) that Emacs 23 should have the multitty functionality.
>   

I am not arguing against including it in Emacs 23, I just think it is a 
mistake to check code that is knowingly broken on some platforms into 
the trunk.
I will put effort into getting it working again on Windows (assuming 
noone else beats me to it), whether it is on a CVS branch or the trunk, 
as I have done with emacs-unicode-2, but due to the time I have 
available this could take a couple of months or more. I don't think it 
is acceptable to have the trunk broken for that long, as it will prevent 
some other developers who use Windows from helping with Emacs 23 
development, if they do not have the w32 api experience to help with 
fixing the multitty breakage, for example they may want to help with 
some Lisp package.

I am not asking that it be flawless before merging, just that it isn't 
horribly broken.

> I have my doubts that if we merge unicode-2 first and postpone
> multitty until all issues with it are resolved, the issues will never
> actually get resolved.  In particular when multitty is not kept
> synched to the trunk after a unicode-2 merge.
>   

Why would you not sync multitty to the trunk after the unicode-2 merge? 
Surely Karoly, Handa and anyone else willing and interested should start 
on resolving the merge problems as soon as possible. Even if we did the 
multitty merge first, we would have the same problems on the unicode-2 
branch, and would require the same people working on resolving them.

> I don't think that this is likely to happen in Károly's private
> repository, I really think that we need to merge it into the trunk for
> a reasonable chance to have this happen.
>   
I agree that it won't happen in Karoly's private repository. I have 
tried using it, but the revision control system he uses seems to be 
unstable (from a user interface perspective), and the instructions he 
gives for checking out no longer work. Reading the the latest quickstart 
guide for bazaar did not really help. But committing it to a branch ASAP 
would let the work commence on stabilizing it on other platforms ready 
for merging into trunk.

> > Your point that Karoly is not going to be available for much longer
> > is a point against merging into trunk quickly IMHO. Either someone
> > else will step forward to maintain that code, in which case it
> > doesn't matter if the merge to trunk happens later, or noone wants
> > to maintain the multitty code, in which case merging into trunk
> > would be a mistake.
> >     
>
> I disagree with that assessment.  It presumes that not making Emacs
> multitty-capable ever is a reasonable option.

It is the only option if we don't have anyone willing to maintain that 
capability. But judging from your activism on this, I don't expect we 
will have that problem.