> The question right now is how to best implement this. Do we add something
> to the bug database to flag bugs in some manner and have a release
> candidate summary page?
>
> Or do we separate it out of the bug database and maintain the list
> manually?
OK, my opinion would be to put a copy of the currently known bugs with the RC
source. To give people a local (ie offline) list to look at. Then, why not
use a ranking scheme, people rate how much they feel a specific bug needs
fixing before the new version.. ie
As a major version say v5 would have lots of new features, but 4.0.6 for
example mainly bug killings with maybe some feature improvements, 4.1 would
contain bug killings (of course) but some new features but nothing earth
shattering, and the bugs should be treated the same way.
For 4.0.6 for example we should be aiming to get rid of all recreatable and
rated "very likely to be found" bugs, with bugs ranking down to "obscure
things unlikely to be found by the masses" - and weight them accordingly, so,
the more likely it is to be found and annoy someone, the more we'd like to fix
it before release. So, to your list, why not just add a voting for the QA
people to vote how likely they feel it would come up/how much they would hope
to see it in the next produce from the dev team?
Is that a reasonable idea?
--
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]
