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
