Rich Freeman posted on Mon, 20 May 2013 13:15:09 -0400 as excerpted: >> Severity and Priority on the Gentoo Bugzilla have always been weird to >> me; I would love to hear from someone who is actually using either of >> those to sort their bugs and using them happily, because the >> inconsistency applied by different people is making a mess of them. > > I suspect we could just get by with one field. > > Typically at work the severity reflects impact of a bug (the effects it > has on customers), and the priority reflects management direction on > what developers should be working on. Our fields are a bit of a > mish-mash of both, and of course maintainers can generally ignore or > work on bugs in any order with little impact on their salary. It does > make sense to distinguish between a bug holding up the next gcc release > (scheduled a week in the future) and adding a desktop entry to a package > that otherwise works just fine.
As a user, I've understood: * Severity is something the user/filer can use. * Priority is strictly for maintainers/teams if they want to use it, NOT the user/filer (unless it's a maintainer filed bug). Thus there's reason to have two separate fields, one that's specifically reserved for the maintainer, one for the user, that a maintainer can choose to ignore if they decide to. Even so, if there's no known-approved reason to set severity, a user should just leave it alone. That means users unfamiliar with gentoo's bugzilla should just leave it alone. Here, I only use severity in a few cases, generally the exception rather than the rule. * If it's an enhancement I mark it as such, and expect maintainer bug priority ranked less urgent as a result. The *.desktop file example someone mentioned goes here, as do, arguably, changes such as the md initscript improvements I filed some years ago (tho those could equally arguably be left as normal by the user and let the maintainer decide, I'd certainly not argue a maintainer changing that to/from enhancement). * If the bug has system-wide or arch-class-wide (all ~arch, for instance) implications, I'll sometimes up severity accordingly, with a note in the text explaining my reasoning. Toolchain or base-system bugs that prevent normal boot or system upgrade arguably fit here, especially if they're on a recently (say a day) unmasked or announced to be unmasked package with arch-class-wide implications, where an immediate remask might be appropriate until the situation can be resolved. * Also, arugably many security bugs could get severity-upgraded, altho with security handled separately on gentoo, I'd discourage that unless again it's something like toolchain or base-system, thus fitting the above system-wide condition. Based on the above, I'd suggest that: * The priority field should be restricted to devs (if it's not already), and that devs who misuse the field on packages they don't maintain be treated accordingly. * The severity field is arguably a candidate for "first gentoo privilege", restricted for ordinary users, but with a moderately liberal "on-request" policy, for users who have demonstrated consistent responsible bug filing, on gentoo bugzy at least, but also those who can point to bugs filed elsewhere in the community, package upstream and peer- distro maintainers, etc. Of course the "first gentoo privilege" is requisite on the appropriate infrastructure being in place to handle it, and would arguably be settable by anyone with higher gentoo bugzilla privs. If implemented, constructing an initial whitelist might be in order. A note in gentoo bugzy suggesting that users can request "severity privilege" in any filed bug, should they believe they can handle it responsibly, could be appropriate as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
