Re: [gentoo-dev] robo-stable bugs

[Rich Freeman <rich0@gentoo.org>]

On Mon, May 20, 2013 at 11:29 AM, Tom Wijsman <TomWij@gentoo.org> wrote:
> This is missing a reference URL or at least the ML thread subject; last
> time I asked, I didn't got either and wasn't able to find this in a
> reasonable amount of time. I find some irrelevant policy discussions
> but nothing that indicates the order in the summary.

Tend to agree, but rather than focusing on figuring out who messed
up/etc, let's just move forward.  The proposed placement of PVs at the
start of the subject line makes logical sense, so we might as well do
it.

Short of making an automated bug reporting policy I'm not sure how to
better document things.  I agree that it is easy to miss stuff in list
archives.  Bottom line is people shouldn't take this stuff personally
- just improve and move on.

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

But, since we're not getting paid it really is more of a
communication/organization tool.  At work when we mark bugs high we
expect them to get fixed, since the devs are paid to work on what we
want them to work on, and if that means leaving the blocker alone
while making the splash screen look prettier that's management's
prerogative.

If we do want to have two fields, then the one should be more of a
factual statement (is it an improvement, something that makes the
package unusable for some users, a regression, something that makes
the package unusable for all users, removal of a blocker, etc -
roughly in increasing severity), and the other a true priority (H/M/L
- which is at the discretion of the maintainer, but perhaps set
initially based on guidelines in order to help them out).

Rich