Interesting comments

[Adam Williamson]

On Thu, 2009-03-12 at 08:52 +0900, John Summerfield wrote:

> > 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.

Yeah, it's not a generally accepted definition and it's not what
Bugzilla exactly intended it for, because Bugzilla was written for a web
browser, not for Linux distributions.

It's just something I came up with myself, but I think it's probably the
most useful way of looking at those two fields in the context of a Linux
distribution, because those are things we actually need to rank bugs by.
Think of the use cases.

Priority will be used by us (Bugzappers) and by releng; it's a
convenient way to look at how important a given bug is to the release,
to rank bugs in that way, and to search on them. Severity will mostly be
used by the maintainers; the main use case for the maintainer of package
'foo' is to find out which bugs in package 'foo' are the most critical.
Since he's just working on 'foo', he doesn't necessarily care how
important they are to the release.

So understanding the two as separate attributes and tracking them
separately is useful for all the most common ways in which Bugzilla is
actually used. (note that at MDV I did rather a lot of packaging as well
as being the Bugmaster, so I was experiencing the system from both
ends.)

MDV's been using this system for a year or two now, and it's generally
well understood and accepted both by the triage team and the package
maintainers. For Fedora we may want to keep using blockers as the main
way for releng to identify blocking bugs, but having a finer grained
definition of how important a bug is in the context of the release is
still sometimes useful for us in QA / Bugzappers. I'd often look through
all the 'high' priority (not quite 'release critical', but important)
bugs for MDV to make sure they weren't being neglected.

> 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.

Well, I'd classify it as priority low, severity critical. I don't see
why it should block a release. Sure, it's crappy code, but it's not
likely to cause anyone any particularly massive inconvenience. I'd
rather have the non-infinite amount of resources we have to spend on
prioritizing release-critical issues spent on things that will
significantly inconvenience large amounts of people. But now we're
getting into specifics rather than procedure, which is a different
debate.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net