[ros-dev] Prelude to voting for the Testing Coordinator Roles and Responsibilities.

WaxDragon waxdragon at gmail.com
Sun Oct 16 15:21:30 CEST 2005

On 10/16/05, Ge van Geldorp <gvg at reactos.org> wrote:
> The only thing that needs changing in that description is remove the
> sentences
> "The TC can decide as his will which bugs to promote to Blocker status
> (thereby blocking a new release), or to demote bugs below that status."

Complete control over Bugzilla was the *only* power specifically
granted to the TC, and it's virtually useless since I'm pretty sure
all Bugzilla users are allowed to chage the severity of a bug.  So
this was just a policy change saying the TC gets the final say on
bugs.  Removing this power simply makes the TC a normal user again.

> and
> "However, in the rare case where it is clear to a majority of developers
> that the decision to block a release is unwarranted, a group of no less then
> three developers, with the approval from a board member, may override the
> TC's decision. Such actions should never have to happen however, and
> communicaton is highly recommended in order to reach a moderated debate."

This was just added as a safety, in case the TC gets disagreeable.  I
have always tried to communicate the status of bugs and get developer
input, such as I was doing when all of these issues came up.

> In my opinion, the developers should determine if a release should be
> blocked, not the TC. This is different from giving the developers the right
> to override the TC. I'm not sure why "a board member" is mentioned here, the
> project is primarily run by the developers, not the foundation board.

These would be the same developers that break the build without
knowing it half the time, and  wouldn't fix some bugs unless

> It would be nice if the TC could provide a list (shortly after feature
> freeze) of the biggest problems the testing team found. I, as a developer,
> would certainly use that list to prioritize what bugs I'm going to work on
> during feature freeze. I do reserve the right however to skip certain bugs,
> because frankly I don't always agree with the classification (example: bug
> 880 which is currently classified as "blocker", but in my view it should be
> "minor" since there is a very easy work around available).

So you would like the TC to toil away testing applications on builds,
making lists of what works and what doesn't, just to have no power to
get anything actually fixed?  Frankly I tire of sitting on IRC begging
people to fix bugs.

880 is not a blocker against 0.2.8, and I was going to reclassify it
as such.  It's not a minor bug to me, Gé, since I boot to cmd and this
breaks ReactOS rather badly for me.  I know cmd as a shell is not
really supported, so I wasn't going to press it.

Does anyone agree with Gé?


More information about the Ros-dev mailing list