Interesting comments

[John Summerfield]

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 at coco.merseine.nu  Z1aaaaaaa at coco.merseine.nu
-- 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:-)