[Top][All Lists]

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

Re: Syncing Gnus and Emacs repositories

From: David Kastrup
Subject: Re: Syncing Gnus and Emacs repositories
Date: Sat, 16 Jun 2007 16:16:52 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

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

>     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

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

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

reply via email to

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