Re: Merging multitty

[David Kastrup <dak@gnu.org>]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> However, I think we more or less agreed that it would be more
>> prudent to merge the multitty stuff first and follow up with the
>> Unicode branch, since that would minimize the merge work on
>> multitty where we have less active expertise to rely on.
>>   
> I don't recall ever agreeing this, although you have asserted so
> numerous times over the last few weeks.

Hm.  Maybe the discussion was inconclusive.

> The merge between multitty and unicode will be the same, whichever
> order it is done in.
> The simple fact is that emacs-unicode-2 is ready to go onto the trunk,
> and the multitty is not due to issues mentioned in the README on
> Karoly's website.

I think we more or less agreed (modulo my possibly biased
recollections) that Emacs 23 should have the multitty functionality.
We are also not going to release Emacs 23 next week, and for people
needing a stable version of Emacs there will be EMACS_22_BASE
resp. Emacs 22.1.

So the trunk means the next place where work is going to commence.  If
more work remains for the multitty branch, that would be reason to
merge it sooner.  Another problem is that Károly is not going to be
around to help much.

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.

So yes, I am aware that multitty will likely destabilize the trunk and
require work until the trunk is useful on all architectures again.

Which is sort of the point: take the multitty branch out of the
X11-only realm and have people work on making it a stable component of
trunk on all platforms.

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.

> 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.  But it is certainly
something that people have wanted for a long time, and it is an
embarrassing shortcoming as compared to, for example XEmacs which has
had this for very long.  While I agree that a merge of multitty will
likely cause some problems, I don't think that "will work out of the
box" should be a criterion at the _start_ of the Emacs 23 process.  We
are not aiming to release Emacs 23 simultaneously with Emacs 22.

multitty is quite an important aspect for operating Emacs as a server.
I don't think we should let the existing code go waste.

If we can't get to a more or less unanimous agreement between the
developers, it will be the call of Richard or a possibly apointed
Emacs 23 maintainer to make.

Of course, I would prefer if we could manage to reach more or less
consent without the need of reverting to authority.

-- 
David Kastrup