26 Oct
2005
26 Oct
'05
9:01 a.m.
From: Royce Mitchell III
Furthermore, the only time the TC's "prioritization" of a bug
is during a release process. For those reasons, based on the
two proposals as they are, I think the voting should be between:
A) 3 devs have the power to overrule the TC regarding a bug's
priority for the purposes of a release.
B) it takes a majority vote to overrule the TC regarding a
bug's priority for the purposes of a release.
The whole point of proposal B is to not give the TC special powers with
respect to a release. In proposal A, the TC decides whether to publish a
release or not (with a possibility to overrule that decision). Personally, I
think that's fundamentally wrong. In my view, the developers are responsible
for the quality of the code, not the TC. If a dev introduces a bug which is
not found during testing, it's still the devs "fault", not the
"fault" of
the testing team. With the devs responsible for the quality, they should be
the primary decision making group on whether to release or not.
Of course, you don't have to agree with my point of view, that's why there
are two proposals up for vote.
Instead of the TC having to fight to prevent a release
he
thinks is necessary, we could have a slightly different procedure:
1) RC is ready for FF. Asks TC for revision to branch. If TC
feels there are too many blockers for FF, he presents a list
of blockers to the list. ( You can't really set up a forum
vote for this - forum votes only allow you to pick one item
from a list. ). We'd have to decide here exactly what kind of
a "vote" this would be - should 3 devs in agreement on a
single blocker be able to enforce the TC's block, or what?
2) The CF process would work the same as FF, except without
the branching, as the code is already branched.
(For the benefit of those wondering about the acronyms: FF = Feature Freeze,
point where we make the release branch, no new features go in the branch,
only bug fixes. CF = Code Freeze, only major bugs are fixed during this
stage, every commit needs to be discussed on the mailinglist first).
The procedure you suggest has the danger of postponing releases indefinetly.
There will always be a feature just around the corner (networking, anyone?)
or a serious bug. I believe we should go back to time-based releases. Every
two months, the release coordinator publishes a release schedule: "we're
going to branch for 0.x.x and enter feature freeze on xx/xx, with code
freeze expected on xx/xx and final release on xx/xx". So, it's possible that
we end up branching with a serious bug present. That bug will be in the FF
(or Preview or whatever you want to call it, the thing we currently call
RC1) which is published on SourceForge. The point of the FF is not to have a
perfect .iso out there, but to get extra testers to find other bugs.
The TC is very important especially during the feature freeze phase. It
would be good to have a list of serious problems (hopefully that list is
empty, by the way) when we enter feature freeze and be able to cross the
problems away as we fix them. It's just that I believe we shouldn't make the
decision to branch based on the problem list, it should be time-based
instead.
Now, entering code freeze is another matter. That's basically the point
where we say "ok, what we have in the release branch is good enough for an
official release". That's why I said "code freeze expected on xx/xx"
above,
the date of a code freeze can and should shift if serious problems are still
present.
Peace
And hapiness to all.
Gé.