I cc'ed the quality alias, since this is a pretty relevant discussion
for that alias.
Bill Shannon wrote:
> Wrong, wrong, wrong.
>
> I see it's time for me to yet again explain how we are supposed to use
> bug priorities. Haven't I done this at least every release for the
> past, oh, I don't know, 8 years?
>
> A bug doesn't have an inherent priority. A bug isn't born with a
> priority.
I thought issues are created with a priority value by the filer....
> The priority of a bug is *our* decision. Not just a technical decision.
> Not just based on the impact of the bug. Not just based on the
> severity of
> the bug. But also based on resource, business decisions, and so on.
A filer doesn't have visibility into these factors, so should all bugs
get filed as P1/unconfirmed?
This would basically mean that the bug must get evaluated and assigned a
priority, before the product can ship?
>
> The priority of a bug is the *output* of our decision making process;
> it reflects what we *decided*, not what a bug *is*.
>
> If we think a bug absolutely, positively, *MUST* be fixed before FCS,
> and if that one single bug is not fixed before FCS we will absolutely
> hold up the release until that single bug is fixed, then we mark it as
> a P3. Similarly for beta, we mark it as a P2. You can probably guess
> how important a P1 bug is.
Fix before next promoted build?
>
> If we just *want* to fix the bug for FCS, that's a P4 bug.
>
> If you have a P4 bug, and you want to fix it for FCS, but you don't want
> to lose track of it, fill in the "target release" field with the name of
> the release where you intend to fix it.
>
> And if there are P4 bugs that you're not expecting to get to anytime
> soon, well, that's why we have P5.
I think this is a reasonable "process"... It is a bit different than the
processes that the help associated with the GF issue tracker presents.
We may want to publish an outline of the process on the wiki for the
community, so filers do not misunderstand the meaning of their P2 bug
being reclassified as a P4 bug...
>
> Do not add keywords to the bugs.
>
> This is the way we manage 900 bugs. We divide them into categories that
> are manageable. The bugs that deserve the bulk of our attention are
> those that we absolutely have to fix no matter what. If there aren't
> many less than 900 of those bugs, we're in deep trouble.
>
> Remember that when you submit a bug.
It is very hard for filers to assign priorities. That is really the
"job" of the person that evaluates the bug.
But, that really means that all bugs that are unconfirmed need to be
treated as high priority issue until they have been evaluated...
For example; in the GF issue tracker there are 375 unconfirmed issues,
291 of them are DEFECTS...
As a person evaluating products based on the GF codebase, this is a very
troubling issue.
To me, at first glance, it looks like there are 291 possible show
stopper issues that haven't been examined.
I know that that isn't exactly true, since I am pretty tied into the
community... Other folks aren't and won't be able to invest the time
vbk
> Remember that when you assign a
> bug. Remember that when you evaluate a bug. If we aren't constantly
> verifying that bug priorities are correct, we'll end up with an
> unmanageable mess of thousands of bugs.
>
>
> Oh, and those bug queries, they're not including all the components
> that feed into GlassFish. We need to count them as well.
>
>
>