Re: [RFC] 3.1 branching

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Thu, 25 Sep 2008 12:57:52 -0600

On Fri, 2008-09-26 at 05:28 +1200, Amos Jeffries wrote:

> The merge queues need to be maintained manually. With this branch there
> are going to be three to process and the more committers, the harder it
> gets to sync them. Thats ignoring Henriks 2.x queues as well for the
> cross-port features.
>
> When I started it took myself and Henrik a good week combined to sync
> just the HEAD and 3.0 queues after everybody committed fixes. It still
> takes me a few hours to check every time Guido commits his Windows bits
> to 3.0. There were a non-zero number of regressions on both HEAD and
> branch encountered during the sync.

Understood. What do you think is better:

A) Branch and commit waiting stuff to trunk now. Deal with a large
volume of complicated commit traffic between the 3.1 branch and trunk.

B) Branch and commit waiting stuff later. Focus on 3.1 leftovers and
stability without being distracted by cross-porting commit traffic.

I would pick B, but since you are handling most of the commit traffic, I
think it is your choice.

> If other committers are needed I think some simple limits are needed to
> make things easier:
>
> * branch commits MUST have a corresponding trunk commit. Branch gets
> cherry-pick merge from trunk whenever possible. Back-ports if not.

Agreed. The more new stuff enters trunk, the more time-consuming
double-commits will become though.

> * anything comitted that you didn't write. remember the Author: tags.

Can somebody (or do we) use Author for copyright-related statements? If
yes, then who wrote the code may be irrelevant in some cases.

> * bug fixes for 3.0 stable still go down through maintainer.

Sure.

> * its hands off everybody except nominated maintainer once the stable
> release is made. Further tweaking can be done in private sub-branches
> and go in through trunk as normal when needed.

Agreed.

> I'm minded to add 'only the developers who are responsible for a new
> feature can commit'. But I know there will be others who can fix some
> bugs too.

Right. There are many bugs/fixes that have no "feature" behind them.

> I'm slightly more than half-convinced. It's much of a sameness as you
> pointed out. I'm willing to trial it and see how things go for 3.1.

Sounds good.
(See, Kinkie, it worked this time! :-).

I think the only big decision left is whether to branch first or
stabilize first.

Thank you,

Alex.
Received on Thu Sep 25 2008 - 18:58:02 MDT

This archive was generated by hypermail 2.2.0 : Fri Sep 26 2008 - 12:00:05 MDT