RE: 4.0.5: Merge Request

> 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?