[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Interesting comments

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

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

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.



-- spambait
1aaaaaaa coco merseine nu  Z1aaaaaaa coco merseine nu
-- Advice

You cannot reply off-list:-)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]