[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] CDT defects and transitioning from 1.2 to 2.0
|
Hi!
It would be cool if you could document the Priorities field at
"https://bugs.eclipse.org/bugs/bug_status.html#priority". That's where you get
by clicking the "Priority" link on any bug's page. You may have to talk to the
JDT PMC about this, but the Priority docs currently say just "P1 - Most
important" and "P5 - Least important".
Also, IMO it would be nice if the enhancement requests should be triaged rather
than just getting P5'd. One way to automate this could be to go by the number
of votes for each of them.
Great that someone is taking control of Bugzilla usage. Way to go!
Cheers //Johan
Kleanthis Hapitas wrote:
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