On Wed, 2 May 2001, Hartmut Holzgraefe wrote:
> Matt McClanahan wrote:
> > I don't see inviting this wider audience as providing enough beneficial
> > information to justify the work of clearing away the less useful
> > reports.
> right now we invite this wider audience the day we release a 'release'
> and again and again we end up with a .pl1
> i just want to get into some process that shifts labels here
> making what we call 'release' now the final release candidate
> so that we end up with a release that deserves this name
> without having an .pl1 attached
> if you do not want to see useless bug reports you should not release
> at all
You aren't going to avoid the useless bug reports completely, but Matt does
have a point that the RC cycle is a time when it's important to be able to
focus on testing and squashing bugs, instead of losing time by hunting through
hundreds of bogus bug reports.
It may be that adding more eyeballs would lead to more bugs being found before
the release, but I don't think that's going to help very much when there's
nothing to stop developers from adding new bugs during the RC series! The
purpose of a release candidate, by definition, is to give people a version of
the code to focus on for bugfixing purposes prior to release *in order to
reduce the number of bugs in the tree at release time*. How can we hope to
have fewer bugs in the final release than there were in RC1, if developers are
allowed to add new features during the RC series? What's the purpose of
having a QA team if you don't give them the *power* to Assure the Quality of
Give the QA team that power. Let the release branch be reserved exclusively
for bugfixes, and give the QA team control over what gets committed to the
branch. This is the only way to make headway against bugs.
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]