Re: Merging multitty

[David Kastrup]

"Juanma Barranquero" <address@hidden> writes:

> On 5/11/07, David Kastrup <address@hidden> wrote:
>
>> It certainly will be more convenient for people wanting to
>> _use_ the trunk as opposed to _work_ on it.
>
> No. It will be more convenient for people wanting to _work_ on the
> trunk on things _other_ than the multitty support.

Good point.  But if other things happen to destabilize the trunk, it
will not exactly help getting a multitty branch into good shape.

>> The second variant makes separate sense of its own mainly if one
>> _delays_ merging the multitty branch until it has stabilized on all
>> platforms.
>
> Which is a fine idea by itself.
>
>> I don't see that happening by magic.
>
> Either there is people willing to fix the problems in the multitty
> branch, and then a branch is fine, or there is not, and then forcing
> it on the trunk it's not going to help much (if anything, it'll
> diminish some people's enthusiasm).

I can see your point.

At any rate, I find that we should move the repository of multitty
_fast_ into the Emacs repository (as a trunk for now), and likely by
way of Miles' arch mirror.

If we don't do that, I don't see multitty going anywhere.

multitty is an architectural change slated for Emacs 23.  trunk or
not, it will be important that people bother with it eventually.  But
it is reasonable to assume that only a subset of the current (and
possibly revived or new) developers will feel able to contribute to
this work, and blocking the others in the mean time does not seem like
a good idea either.

I would however think it prudent to _first_ have the multitty branch
put into place and synchronized before we do the unicode-2 merge into
the trunk.  That will be the best shot we may have at keeping the
multitty branch in a state where its developers have mostly to worry
about multitty issues.

And it would be good if people familiar with unicode-2 would also help
with merging the trunk change into the multitty branch (since they
probably will best know how to deal with the conflicts).

In short: even if we put multitty into a branch, we should give it the
best kickoff we can manage.

-- 
David Kastrup