Re: unicode-2 and multitty

[David Kastrup]

Jason Rumney <address@hidden> writes:

> David Kastrup wrote:
>> I know that there are a few prepacked "Emacs-23" variants around:
>> would it be acceptable to the maintainers of those if the unicode-2
>> branch were to go through a period of relative instability caused by
>> the merge of multitty?
>>   
>
> Since multitty has never been in CVS, it hasn't had as widespread
> testing as unicode-2, especially on non-unix/GNU platforms. So it is
> probably better to create a new branch, and first import the multitty
> code from its current repository, then merge in the unicode-2
> changes. Once that branch is stable, we can abandon the unicode-2
> branch and use the new branch for all "future" development.

Since the file structure of the multitty branch supposedly will see no
further changes, an import into CVS will probably not make development
harder.

Károly, do you think you could create a branch and do that with an
updated version of the multitty stuff?  There is probably little sense
in importing your personal change history.

Since the goal after the multitty merge would be merging unicode-2, it
would likely make sense to name the branch multitty-unicode-2.

Since this step would more or less imply a bit of passing of
responsibility for the multitty work, this basically makes sense only
if there is a non-zero number of developers who would be willing to
spend the time necessary for occasionally synching to HEAD while HEAD
still changes (as long as HEAD does not diverge from the release
branch, this should not be too much work, and once it is allowed to
substantially diverge, it would be time to replace it by the
multitty-unicode-2 branch, anyway).

There will also be the one-time work to merge unicode-2 into it.
Since both multitty and unicode-2 are currently close to HEAD and the
functional overlap of the branches is small, the initial merge should
likely not require an overwhelming amount of manual work.  Getting the
merge to actually work might be a different thing, however.

It is likely that people (like myself) who have grown accustomed to
using their CVS version of Emacs also for production work will have to
keep a binary from the HEAD branch around for a while until the merge
has converged to a reasonably compilable and crash-free state.

But I think this should be doable.  It also does not appear to me like
the pace of the Emacs 22.1 release would be significantly affected by
this diversion of developers moving to a new branch.

>From a project management point of view, it could possibly make more
sense to actually do this work in HEAD.  While I personally consider
the point of the release branching to have been that HEAD can move on
to the next development phase, this will be Richard's call to make.

Creating a separate multitty-unicode-2 branch leaves open the choice
when to move the HEAD attention (usually the principal focus of
developer interest) to the remaining Emacs 23 work.

-- 
David Kastrup