Re: [RFC] 3.1 branching

On tor, 2008-09-25 at 12:57 -0600, Alex Rousskov wrote:

> 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.

How much of that waiting stuff is major changes touching large parts of
the code base?

Without any such change the two is close to equal from a stable branch
maintenance perspective.

What can be seein in Squid-2 is that bugfixes which enters 2.HEAD still
migrates pretty much effordless down to 2.6 via 2.7, even when the
distance between 2.6 and 2.HEAD is by now quite large. Probably they
would merge pretty much effordless very many releases back.

> > * 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.

It's for tracking the author mainly. Copyrights is kept within the
content, not the merge messages.

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

My vote:

1. Finish any pending major restucturing/reorganisations/reformmatting
first. For example if the code is to be restyled before 3.1 is "old and
mature" then it must be done before 3.1 is branched. Such changes is a
major blocker for branching.

2. Branch so 3.1 can start it's road to stabilization in a sensible
manner. It does not really matter if it's 100% feature complete, or if
there is some already committed features which isn't quite finished.
Small features is no different from bugfixes in terms of maintenance,
and if it's found there is committed unfinished stuff already in the
tree then it can quite easily be bounced to the next release after
branching (but not before). Also if now missing features gets further
delayed they simply won't make it in time for the release and will get a
new chance in the next release (3.2).

3. flame anyone who commits bugfixes embedded within feature commits.
Bugfixes need to be separate for the maintenance process to work. Any
bugfixes committed as part of feature commits gets hidden and lost from
the maintenane process.

Regards
Henrik