[gentoo-dev] Re: robo-stable bugs

[Duncan]

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