Re: Merging multitty

[David Kastrup]

Kenichi Handa <address@hidden> writes:

> In article <address@hidden>, David Kastrup <address@hidden> writes:
>
>> So yes, I am aware that multitty will likely destabilize the trunk and
>> require work until the trunk is useful on all architectures again.
>
> At least, merging unicode-2 doesn't make the trunk unuseful
> for any architecture, so I think it must be the first.

That is assuming that the trunk should always be working for all
architectures.  I have my doubts that this is the best way to make
progress.  It certainly will be more convenient for people wanting to
_use_ the trunk as opposed to _work_ on it.

At the current point of time, the trunk _is_ more or less what people
are used to using for their everyday work, and snapshots are made from
it and provided as packaged, useful variants of Emacs.

I am not convinced that we will make speedy progress to Emacs 23 if we
insist on maintaining this state.  I think that it is more reasonable
to have this sort of stability on release branches rather than the
trunk.  In particular when we are talking about the _start_ of a new
version.

> Currently Miles is synchronizing unicode-2 to the trunk
> periodically (great thanks for that effort).  If we merge
> multitty to the trunk at first, and make the trunk unuseful
> for some architecture, unicode-2 branch will also be
> unuseful for that architecture after Miles synchronization,
> which I do want to avoid.

A valid concern.  It would probably make sense to cease the
synchronization while the work on multitty is stabilized.

> Unicode branch has been there for more than 5 years, and we should
> think that it is a kind of big bugfix for the current
> weird/complicated character handling.

The concern seems to be that people want to have some more-or-less
stable version of unicode-2 that is kept up-to-date with other work.

If we merge unicode-2 first, the unicode-2 branch is dead.  When
merging multitty afterwards, there will be no current variant of
unicode-2 without multitty.

Merging multitty first will leave us with the following:
a) a release (or release branch) for Emacs 22
b) a destabilized trunk containing multitty that needs to get brought
   up to scratch on all platforms
c) a unicode-2 branch that continues to provide something from which
   one can snapshot Emacs 23.0

Merging unicode-2 first will leave us with:
a) a release (or release branch) for Emacs 23
b) a trunk from which one should be able to provide Emacs 23.0
   snapshots soonish, but without multitty.
c) a multitty branch that needs to get merged with the trunk now
containing Emacs 23.0

The second variant makes separate sense of its own mainly if one
_delays_ merging the multitty branch until it has stabilized on all
platforms.

I don't see that happening by magic.

In short: I am afraid that the second variant will be a "shortcut"
that will not lead to a faster release of Emacs 23, but rather provide
us with a longer "comfort period" on the trunk where the multitty
problems are not being addressed seriously.

-- 
David Kastrup