Re: [cdt-dev] CDT defects and transitioning from 1.2 to 2.0

[Kleanthis Hapitas <khapitas@xxxxxxxxxx>]

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