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