Re: Syncing Gnus and Emacs repositories

[David Kastrup]

YAMAMOTO Mitsuharu <address@hidden> writes:

>>>>>> On Sat, 16 Jun 2007 15:13:40 +0200, David Kastrup <address@hidden> said:
>
>> Frankly, I don't see the point in not merging either.  I don't see
>> that the trunk accomplishes _any_ function in connection to Emacs
>> development that would not equally well be accomplished if unicode-2
>> was merged.  We don't need a "stable" trunk: we have EMACS_BASE_22
>> for that purpose.
>
> I had an impression (yes, just an impression) that:
>
>   EMACS_BASE_22: to become the next bugfix release 22.2.
>     Only bugfix changes should go there.

Pretty much the point, though it is not clear whether some other
stuff, like package updates will happen there, too.

>   trunk: to become EMACS_BASE_22 after the 22.2 release.

That would make no sense.  The point of the branch was to get a stable
basis.

>     Changes common to 22 and 23 should go there.

Frankly, I don't see that we can afford separate 22.x and 23.x
development lines.

>   emacs-unicode-2: to become the trunk after the 22.2 release.
>   Changes specific to 23 (but not multi-tty-specific) should go
>   there.  Changes made to the trunk also go there by regular
>   sync. by Miles.
>
> But as Richard said multi-tty changes could also go to the trunk
> under a certain condition, this impression will never be true at
> least in a strict sense.

At the risk of repeating myself: active branches are expensive with
regard to developer mindframe and feature availability (having the
features of more than a single branch lets the merge efforts explode
exponentially).

We should clamp down on active branches whenever we can.  If two
active branches have no separate release goals, maintaining them
separately is a cost in complexity and mindshare that we should not be
affording without very good reason.  EMACS_22_BASE is for 22.x,
unicode-2 is clearly for 23.x, trunk has no clear release goal
whatsoever.

Branches and functionality like antialiasing, xft, bidi and others
don't make much sense basing off or synching with a non-unicode-2
trunk.  Neither does it make much sense to add new input encodings and
similar stuff that is likely to interact with unicode-2 differently
than with Emacs 22.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum