Re: 4.0.6

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 the release? 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. Steve Langasek postmodern programmer