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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
