On Mon, May 20, 2013 at 11:29 AM, Tom Wijsman <tom...@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
