Re: [gentoo-dev] Re: robo-stable bugs

[Jeroen Roovers]

On Tue, 21 May 2013 00:46:22 +0000 (UTC)
Duncan <1i5t5.duncan@×××.net> wrote:
> As a user, I've understood:
>
> * Severity is something the user/filer can use.

So when Chromium doesn't compile on your machine, you set it as a
Blocker, and then it gets reverted to Normal because it works fine for
the other 99,9%. Individual users are probably not best suited to
discover the scope of a bug report, let alone the actual bug, if there
is one. If the Severity does not get reverted to Normal, then we can
safely assume it's being completely ignored.

The interpretation of Severity is highly dependent on the type of bug
report. It's already diverting strongly between stabilisation requests,
security vulnerabilities and changes to documentation. The meaning of
the field thusly changes according to the Product/Component and other
fields.

> * Priority is strictly for maintainers/teams if they want to use it,
> NOT the user/filer (unless it's a maintainer filed bug).

There is no policy here except where herds/teams specifically set them
out.

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

Agreed.

> * 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,

What if a bad/missing .desktop file stops you from running an app
through your DM/another app trying to find an appropriate program to
open a file in?

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

What if your initial analysis completely misses the mark? Then you
end up with an INVALID Blocker with one or more devs investigating
hours in a user error. How did setting Severity help here?

In conclusion, setting Severity can only be properly done after an
actual bug has been appreciated, not at the time you file the bug
report.

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

As explained above, the security team has its own rules.


     jer