25 Oct
2005
25 Oct
'05
9:55 p.m.
Ge van Geldorp wrote:
There was some confusion and disagreement about the
Testing Coordinator
function description recently. The best way to solve it seems to be a vote.
With the new voting procedure established and 0.2.8 (almost) out the door,
this seems a good time to start the voting process. Our (draft) constitution
calls for a 5 day discussion period, followed by a 5 day voting period. This
email starts the 5 day discussion period. Preferred location for the
discussion is the ros-dev mailing list, since all developers have easy
access to that. At the end of the discussion, I'll post a call for votes to
the mailing list and create the vote on the forum.
We have two proposals for the TC function description, A and B. A is the
original function description. Proposal B is almost the same, the only
difference is that the TC does not have the authority to block a release.
This is the motion I would like to vote on:
"Do you want to:
A) set the function description for the TC role as described in
http://www.reactos.org/wiki/index.php/ReactOS_Testing_Coordinator or
B) set the function description for the TC role as described in
http://www.reactos.org/wiki/index.php/ReactOS_Testing_Coordinator_Alternate…
Gé van Geldorp.
Under "Alternate" URL, Section "Powers", 2nd paragraph, you
have:
"...hinder any legitimate efforts...". I think the word legitimate is
too vague here, and the sentence should be changed to be more precise.
I'm having a difficult time coming up with an alternate suggestion, so I
figured I'd think aloud here... All powers granted by voting people into
positions are temporary. We are not setting anybody up as god. So in
either scenario, there has to be the ability to overrule the TC.
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.
Moreover, I'm thinking maybe there's another way to skin this cat...
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.
The advantage of doing it this way is we already have a list of "known
bugs" we can apply to the release if we decide to go forward.
Anyways, just some random musings...
Peace