Re: [RFC] 3.1 branching

Alex Rousskov wrote:
> On Thu, 2008-09-25 at 17:49 +1200, Amos Jeffries wrote:
>>> So how do we tell users to try something between 3.1.0 and 3.1.1? Refer
>>> to some specific daily snapshot? Kinkie+ scheme would use numbered beta
>>> releases: 3.1.0.1, 3.1.0.2, etc.
>>>
>>> I think numbered releases are better than daily snapshots for asking
>>> users to try something: "Argh! Somebody committed a bug 5 minutes before
>>> the snapshot we thought we would recommend to the user. Let's wait
>>> another day and hope that it does not happen again. People! Please do
>>> not commit anything because we need a clean daily snapshot!".
>> Thats all in trunk. We are talking numbering systems for the branches.
>
> I am talking about the freshly branched branch, not the trunk. Snapshots
> are fine for the trunk.
>
>> To which the only commiter should be the branch maintainer.
>
> This is a different issue, but I do not think that limiting access is a
> good idea until the branch becomes stable. When 3.1 is branched (which
> you want to happen soon), there will be a lot of cleanup work still
> going on. I see no reason to make that work go through a maintainer. If
> that is indeed a requirement, we should not branch 3.1 for now.

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.

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.

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

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

  * 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.
But please, work down through trunk as a first choice.

>
>> We can make a
>> new clean snapshot at any point if its really warranted, even to the point
>> of calling it a 3.1.0.1 'release' 3 times in one day.
>
> Yes, in Kinkie+ scheme, we can. You scheme does not mention 4-digit
> releases, even for the branch in a development stage.
>
>>> The extra "development release" layer in Kinkie+ scheme is only used for
>>> 3.1.0, never for 3.1.6 or other non-zero releases.
>> This is a contradiction of your earlier how do we tell users to try
>> something between 3.1.0 and 3.1.1?"
>
> I do not see a contradiction. 3.1.0.x releases are expected. 3.1.1.x
> releases are not.
>
>> The 'please try X' request is done as often after 3.1.1 as before.
>
> If 3.1.1 is stable, than the number of such requests would be low enough
> to be satisfied with patches and such. The next "official" trial point
> would be 3.1.2.
>
>> We come back to the problem of until squid is 100% major bug free for all
>> users (now and in future) it never actually qualifies for that 3.1.1
>> rating.
>
> Correct. That is why we want 4-digit releases to test how stable the
> branched code is. The more stable it gets, the more users will try them,
> and the more confident we will become that it is indeed stable. At some
> point, we will release 3.1.1 and mark the branch as stable.
>
>> Under my scheme, we would not grant such development test points a full
>> version number, they can get a rc1, rc2, etc (or as at present a
>> '20080912') if needed.
>
> That was your original proposal, yes. So Kinkie suggests 4-digit
> development versions. You now re-suggest 3-digit plus rcW for the same
> purpose. IMO, Kinkie's scheme is better because not all those snapshots
> are actually "release candidates". Again, it is better to leave complex
> metadata outside of the release version or tag.
>
>>>> People seem happy with the release approach and timelines, just not the
>>>> current bad naming scheme which implies releases are guaranteed STABLE
>>>> when in fact only a bug fix improvement.
>>> Well, there are several problems with the current scheme, but I think we
>>> should preserve the notion of a "stable" state of the branch. It is not
>>> a guarantee, but it allows users to select the right branch/version to
>>> deploy. In Kinkie+ scheme and in your scheme, the branch is considered
>>> stable when 3.1.1 is released. Before that, there are big known bugs.
>>> After that, there should not be any and those that appear should get
>>> higher fixing priority.
>>>
>>> The only significant difference I see is that you want folks to use
>>> daily snapshots during "development" stage of the branch and Kinkie
>>> wants sub-numbered releases.
>> Yes, pretty much.
>> If you look at the changeset pages for each 3.0 release so far, there are
>> fixes for some very major bugs in there as far as 3.0.STABLE7.
>
> Yes, and that is OK. Stability does not guarantee lack of bugs.
>
>> If we had run a whole cycle of 3.0.0.N (aka 4 years of testing PRE1 ->
>> RC2), we would have still probably have released 3.0.1 (aka 3.0.STABLE1)
>> with those bugs in. Or maybe gone straight from 3.0.0.16 to 3.1.0.1 this
>> month
>
> Again, there will be no 3.1.0.1. Once the branch is marked as stable, we
> stop doing intermediate development releases. That is my understanding
> of what Kinkie and Henrik want, anyway.
>
>> I don't realistically expect 3.1 to be perfect either.
>>
>> I'd rather have fixed point releases (3.0.1) based on some known workable
>> code, and a pile of sequentially tagged bundles of 'maybe dodgy code' on
>> top for new un-tested bug fixes.
>
> Sure, the only need that we need to address for those bundles during
> non-stable branch development is that the bundle is not controlled by
> time, but by a human decision to tag/release it.
>

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.

Amos

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE9