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?

logdaemon, internal redirectors, and netdb are big component changes. But
not squid-wide.
The cleanup merger is much closer to squid-wide surgery as all file
includes get touched in some way. That HAS to wait for reformat, layout,
and trunk to settle post-branch.

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

Ditto. Those are down as 'features' blocking branch. Only the src/ folder
re-org may cause delays.

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

That last is already on the books. Only eCAP is blocking right now because
it was cemented and guaranteed before the flexible feature track was
taken.

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

We seem to have an agreement. Now lets get back to code and bug eh?

Amos
Received on Fri Sep 26 2008 - 01:25:22 MDT