Re: [RFC] 3.1 branching

On tor, 2008-09-25 at 08:11 -0600, Alex Rousskov wrote:
> 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.

In the somewhat raw branch maintenance process we have it's important
that everyone who commit on a stable branch follow the procedure in
tracking the merges, or you'll actually increase the workload of the
branch manager. It's better stuff gets committed to HEAD and then asked
to have them backported to stable.

I have some ideas on some simple tools to fix that, but time is a
limiting factor..

The exception is issues which are unique to the stable branch, or which
requires effort to backport.

Issues unique to the stable branch is generally fine to commit directly
there, as that's the startingpoint for tracking that change.

For issues requiring effort to backport there is no simple answer.

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

Which is the time where 3.1.2 is labelled a RC. Tarball rolled, but not
yet on the FTP server or announced on squid-announce, and labelled as an
release candidate on the web server.

Before that there is also the nightly snapshots which works well for
testing of the upcoming release, so the number of times a RC fails
should be nearly zero. But it's still a timeframe which is needed to
ensure we do not label obviously broken releases as "stable".

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

Yes. It's pointless during a stable cycle as the number of fixes between
the patch releases is quite small, has been tested & verified in HEAD
and as individual patches or nightly snapshots.

The number of times RC releases has been used between STABLE releases in
Squid-2 can probably be counted on a single hand, and nearly all times
it's been things which really belongs in the next release number and not
a patch release. I can only remember one time where it was due to a
major bugfix (the 2GB barrier) and even then that's probably more
suitable for the next release.. So the main reason why RC releases has
been seen between STABLE patch releases is due to the somewhat twisted
release process we had for Squid-2 with "no further releases" forcing
these rather major changes to take place during a stable cycle.

Regards
Henrik