emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Merging multitty (was: Reordering etc/NEWS)


From: David Kastrup
Subject: Merging multitty (was: Reordering etc/NEWS)
Date: Fri, 11 May 2007 10:44:58 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

Kenichi Handa <address@hidden> writes:

> In article <address@hidden>, Richard Stallman <address@hidden> writes:
>
>> So people can use the trunk for changes meant for Emacs 23.
>
> Does it mean that it is ok to merge emacs-unicode-2 into the
> trunk now?

Well, this is one of the points we definitely agreed to do for Emacs
23, so it _would_ appear to be in concord with Richard's statement
here.

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.

Cc to Károly and the multi-tty list.

In either case, a merge into trunk is quite a bit of work, so it would
certainly not do harm to ask Richard for the explicit goahead if we
can agree on the procedures.

The last updates of multitty appear to have happened on Apr 22nd.
Károly, would it be possible for you to synch one last time to the
trunk and then check the results into a branch in Emacs CVS?

I would propose the following procedure:

a) Károly synchronizes his version to the trunk [very desirable]
[after this has happened, we may already have word from list
participants and Richard whether we can agree on this procedure]
b) if he has CVS write access, he checks the results into a branch
   emacs-multitty.  If he hasn't, we need someone else to do this.
c) The branch is merged into the trunk.  If point a had already been
   done by Károly, this will be trivial.  If he has not been able to
   do this, more work will be involved, but I don't expect serious
   merge conflicts.
d) problems are shaken out.  This will particularly affect platforms
   not yet tested/implemented in multitty.
While d) happens, emacs-unicode2 is synchronized according to what the
developers of the branch feel appropriate.  Synchronizing with the new
trunk will mean that there will be no production-quality
emacs-unicode2 until the trunk has stabilized again.
e) once the worst appears to be over, emacs-unicode2 is merged.

_Afterwards_, pent-up package updates reserved for "post-release" will
get merged.

This means that merge conflicts due to the multitty and unicode
changes will have to be tackled by the people checking in the package
updates.

Comments, better ideas?

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]