>> - 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: the milestone field is not visible in search lists (maybe
>> this can be changed)?
> 
> I think using the milestone will get us more confused only.  We already
> have the issue that what we make a blocker (P1) for 4.4 is not a blocker
> for, say, 4.3.4.  Unless we want to start duplicating bugs for each open
> branch I'd rather not touch our target milestone policy.

Right now the target milestone is useless, as it could be computed
algorithmically:

   [4.2/4.3/4.4 regression] -> milestone is next 4.2 release
   [4.3/4.4 regression] -> milestone is next 4.3 release
   [4.4 regression] -> milestone is next 4.4 release
   else -> milestone not used

The situation that you mentioned (P1 for 4.4 but not for 4.3.4) would be
handled by having [4.3/4.4 regression] with milestone of 4.4.  This is
why I think the more aggressive usage of the milestone field would be
advantageous.

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

Paolo

Reply via email to