Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] CDT defects and transitioning from 1.2 to 2.0


All,

You may have been receiving emails recently notifying you of changes to bugzilla defects. Its related to some clean up work I'm doing as we transition from 1.2 to 2.0. For details, read on and if the emails are a nuisance you may want to limit the kinds of notifications you receive from bugzilla.


First of all, I have taken all of the unresolved defects and set their target milestone to 2.0 (they used to be all over the place). For any defects that we will want to deliver in a patch release prior to 2.0, we can change the target once we make that decision. (As Doug has already pointed out, we'll need a 1.2.1 target milestone set up for such defects)

We are heading into the next release with 265 unresolved defects in total (0 blocking, 0 critical, 16 major, 223 normal, 14 minor, 2 trivial). While defect severity is an important consideration, the priority field is what product groups typically use to distinguish between defects in terms of which release they should be addressed in. I'd like to see us start using this field, with P1 being defects that MUST get fixed in the next release (ie they would gate the release if not fixed), P2 = Fix if at all possible, and so on. Of course there can be good reasons for deciding NOT to fix a high severity defect in a current release, and the priority field is the way to deal with that.

If nobody has any objections, I'll set up the priority of unresolved defects as follows:

   P1 (must fix and would consider gating the release) = blocking and critical severity
   P2 (fix if at all possible but don't delay the release) =  major severity
   P3 (would be good to fix, time permitting)  = normal & lower severity
   P4 (we suspect we won't be able to fix in next release) = normal & lower severity
   P5 (if we had unlimited resources....)                        = enhancement level severity


Now for RESOLVED defects, the ones we care the most about are those that have actually been fixed and should be verified. Ideally you want to verify ALL defects that were fixed in a release before sending it out, but sometimes that is not practical. We went to 1.2 GA with a bunch of unverified defects, and I've moved the target for those defects to 1.2, to distinguish them from defects that are resolved in the next upcoming release. I'll send out a list periodically with outstanding defects that were fixed and should be verified, but when a release has been out there for a good while we can probably consider most defects to have been "verified by the user community" and hence close them so that the list remains manageable.

For defects that were resolved with a result other than fixed, here is what I want to do (again barring any serious objections) so that queries on unverified defects become much simpler:

result = invalid:        this indicates the problem described is NOT a bug, so close them
result = won't fix: this indicates that there is a problem, but we don't intend to fix it anytime soon. These should be reopened with a very low priority P4 or P5 (who knows, someday...)
result = later: this acknowledges a problem that we intend to fix in a subsequent release. These should be reopened with the appropriate target milestone set
result = works for me: this indicates that the problem cannot be reproduced. The reporter should verify that indeed the problem has gone away and either close or reopen as appropriate. Leave these as is.


Cheers,

Kleo Hapitas
Program Manager
IBM Software Group - Rational
Tel: (613) 591 2913




Back to the top