The current system for managing bugzilla priorities has a major problem,
in that it does not identify bugs that reasonably cannot be fixed before
the release.
The current set of priorities is in practice like this:
- P1: most wrong code bugs, and other absolutely blocking problems
- P2: problems
On Fri, Feb 6, 2009 at 11:30 AM, Paolo Bonzini wrote:
> The current system for managing bugzilla priorities has a major problem,
> in that it does not identify bugs that reasonably cannot be fixed before
> the release.
>
> The current set of priorities is in practice like this:
>
> - P1: most wron
On Fri, Feb 6, 2009 at 8:30 AM, Paolo Bonzini wrote:
> Disadvantages: the milestone field is not visible in search lists (maybe
> this can be changed)?
This issue of the search list has come up so many times. You can
change the search list display with different fields. I usually add
"last modi
On Fri, Feb 6, 2009 at 5:30 PM, Paolo Bonzini wrote:
> The current system for managing bugzilla priorities has a major problem,
> in that it does not identify bugs that reasonably cannot be fixed before
> the release.
>
> The current set of priorities is in practice like this:
>
> - P1: most wrong
>> - The more conservative one is to use more aggressively the release
>> milestone field. Hard-to-fix bugs would be left as P2, but bumped to
>> the next major release at the beginning of stage 3.
>>
>> Advantages: no need for churn in the bug database---very easy to implement
>> Disadvantages:
Paolo Bonzini wrote:
>> I think the only reasonable release criteria is zero P1 regressions over
>> some period. 50 P2 regressions doesn't make a release blocker, neither
>> is 49 P2 regressions a clear sign for a non-blocked release.
>
> I agree.
I mostly agree. P1 regressions are, by definit
On Wed, Feb 11, 2009 at 7:56 PM, Mark Mitchell wrote:
> Paolo Bonzini wrote:
>
>>> I think the only reasonable release criteria is zero P1 regressions over
>>> some period. 50 P2 regressions doesn't make a release blocker, neither
>>> is 49 P2 regressions a clear sign for a non-blocked release.
>
Richard Guenther wrote:
>> However, I don't agree that P2 regressions aren't a factor. If we have
>> a ton of crashing on wrong-code, etc., regressions that adds up to a
>> release that won't work well for people.
>
> In which case the important ones should be P1 ...
No, that misses the point.
>>> However, I don't agree that P2 regressions aren't a factor. If we have
>>> a ton of crashing on wrong-code, etc., regressions that adds up to a
>>> release that won't work well for people.
>>
>> In which case the important ones should be P1 ...
>
> No, that misses the point. A mass of bugs, e
Paolo Bonzini wrote:
> Still, I would like to hear an opinion on what to do with regard to
> long standing bugs that are clearly not going to be fixed in stage3/4.
> This was the main point of my message.
I don't see any need to do anything different; I think we're all capable
of distinguishing
10 matches
Mail list logo
