16 Oct
2005
16 Oct
'05
1:21 p.m.
On 10/16/05, Ge van Geldorp <gvg(a)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
harrassed.
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é?
WD