[ros-dev] TC function description: opening discussion prior to vote

Royce Mitchell III royce3 at ev1.net
Tue Oct 25 23:55:41 CEST 2005

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


More information about the Ros-dev mailing list