Adam Williamson wrote:
On Wed, 2009-03-11 at 11:10 +0900, John Summerfield wrote:
Adam Williamson wrote:
Priority and severity can be set by reporters in MDV Bugzilla. It was my
experience that reporters would frequently inflate these values in their
initial reports. However, if a triage team member then re-set them to a
Last I looked (which was a while ago) there was no apparent definition
of that these mean. Let me think:
Critical - system unusable
Serious - system usable with some impairment, or critical but with a
workaround.
Moderate - causes occasional outages, misleading diagnostic messages
Cosmetic - spelling/grammar errors
Enhancement Request - not exactly a bug, but ....
Everyone would probably agree that, if the system won't boot, that is
critical. I would expect such a critical error would be a candidate
release blocker.
Probably, most would also reckon that a daily crash would qualify as
critical, as would any major component such as X failing.
Here are my definitions from the MDV pages I linked to:
---
For Priority:
The release_critical priority is only relevant to bugs filed on Cooker
or beta releases, and should only be used for issues which are
sufficiently critical that it would severely impair the overall quality
of a release if it were made available without the issue being resolved.
The high priority should be used for issues which are sufficiently
critical that resolving them should take priority over resolving other
issues, but which do not meet the criteria for release_critical. The low
priority should be used for bugs which are sufficiently trivial and/or
limited in impact that resolving other issues should take precedence.
The normal priority should be used for all other issues.
For Severity:
The critical severity should be used for bugs which render a package
essentially unusable (for instance, crashes which would affect the
majority of uses of a package, or total inability to install or run the
package). The major severity should be used for issues which render a
significant feature of the package unusable, or which render the package
generally unstable. The minor severity should be used for issues which
have only a limited impact on the usability of a package or which will
only affect a small minority of users or use cases, and the trivial
severity should be used for issues which have almost no material impact
on the usability of a package. The normal severity should be used for
all other issues.
---
(Mandriva's values are slightly different from the ones in Fedora, but
you can see my general scheme.)
What's not 100% clearly explained in the above is the distinction
between priority and severity. Severity is how bad the bug is. Priority
I don't recall such a distinction, and in my previous life it wasn't
necessary. OS itself was basically the operating system and a bunch of
utilities. They all had to work, but a fault in one of the utilities
probably wasn't going to be critical.
Then users added other software, IMS (Instant Machine Sale) was one.
Westpac's ATM network was down for two or more days following an IMS
upgrade. I guess that qualified as "critical" even though they could
work "with impaired function." (batch work, of which there would have
been a lot, probably was okay). Certainly, IBM gave it very close
attention indeed.
is how quickly it needs to be fixed. These obviously relate to each
other, but they are not the same thing. Most obviously, the importance
of the package to the distribution matters to Priority but not to
Severity.
A crasher bug is always high severity, but if it's in a package that
only three people in the world use, or a package that's just not very
important (xeyes, say), then it's not high priority.
A broken icon or typo is low severity, but if it's something highly
visible - say, it's right on the default desktop - it may be high
priority.
That's how I look at them, anyway.
There is a package I mentioned here a while ago that simply does not
work. I can't remember now what it was, but it expected to run as
root(!!) and interact with a logged-on user via X(??).
It was being started by some hardware event (I'm thinking scanning, but
it's not SANE. Something similar?), and has no access to whatever X
requires for a program to authenticate so that it can display on the screen.
Ah. There's a program that is supposed to respond to button-presses on a
scanner. buttond or some such.
Its presence doesn't much affect the release, but in the context of
_that application_ I'd classify it as critical, a release blocker and
simply omit it unless someone (the packager?) actually tested it and
made it work.
Whatever he agreed guidelines are, they need to be visible to the people
reporting bugs. If someone changes them, then they need to justify the
change - why the current setting doesn't match the guidelines. U'm sure
that, sometimes a candidate change is arguable one way or the other. In
such cases, a change probably should not be made. When it gets down to
it, eventually the package maintainers will make up their own minds and
likely take into account such essential criteria as how much time they
have "right now," how difficult/interesting it is and their own
perception of its urgency.
--
Cheers
John
-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx Z1aaaaaaa@xxxxxxxxxxxxxxxx
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
