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
signature.asc
Description: This is a digitally signed message part
