Skip to main content

[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


I suspect the reason for the vague definition of the "Priority" field is because priority is sooooo subjective. I will ask though...

I agree with you that automatically giving all enhancements the lowest priority is not the best way to approach them, so I'll leave them as is for now and take a look at ranking them according to vote numbers.

Thanks for taking the time to provide some feedback!

Regards,

Kleo




Johan Walles <d92-jwa@xxxxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

10/17/2003 03:28 AM

Please respond to
cdt-dev@xxxxxxxxxxx

To
cdt-dev@xxxxxxxxxxx
cc
Subject
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
>
>

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top