This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposal for improved management bugzilla priorities/release criteria
>> - 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