| 1 |
On Mon, May 20, 2013 at 11:29 AM, Tom Wijsman <TomWij@g.o> wrote: |
| 2 |
> This is missing a reference URL or at least the ML thread subject; last |
| 3 |
> time I asked, I didn't got either and wasn't able to find this in a |
| 4 |
> reasonable amount of time. I find some irrelevant policy discussions |
| 5 |
> but nothing that indicates the order in the summary. |
| 6 |
|
| 7 |
Tend to agree, but rather than focusing on figuring out who messed |
| 8 |
up/etc, let's just move forward. The proposed placement of PVs at the |
| 9 |
start of the subject line makes logical sense, so we might as well do |
| 10 |
it. |
| 11 |
|
| 12 |
Short of making an automated bug reporting policy I'm not sure how to |
| 13 |
better document things. I agree that it is easy to miss stuff in list |
| 14 |
archives. Bottom line is people shouldn't take this stuff personally |
| 15 |
- just improve and move on. |
| 16 |
|
| 17 |
> |
| 18 |
> Severity and Priority on the Gentoo Bugzilla have always been weird to |
| 19 |
> me; I would love to hear from someone who is actually using either of |
| 20 |
> those to sort their bugs and using them happily, because the |
| 21 |
> inconsistency applied by different people is making a mess of them. |
| 22 |
|
| 23 |
I suspect we could just get by with one field. |
| 24 |
|
| 25 |
Typically at work the severity reflects impact of a bug (the effects |
| 26 |
it has on customers), and the priority reflects management direction |
| 27 |
on what developers should be working on. Our fields are a bit of a |
| 28 |
mish-mash of both, and of course maintainers can generally ignore or |
| 29 |
work on bugs in any order with little impact on their salary. It does |
| 30 |
make sense to distinguish between a bug holding up the next gcc |
| 31 |
release (scheduled a week in the future) and adding a desktop entry to |
| 32 |
a package that otherwise works just fine. |
| 33 |
|
| 34 |
But, since we're not getting paid it really is more of a |
| 35 |
communication/organization tool. At work when we mark bugs high we |
| 36 |
expect them to get fixed, since the devs are paid to work on what we |
| 37 |
want them to work on, and if that means leaving the blocker alone |
| 38 |
while making the splash screen look prettier that's management's |
| 39 |
prerogative. |
| 40 |
|
| 41 |
If we do want to have two fields, then the one should be more of a |
| 42 |
factual statement (is it an improvement, something that makes the |
| 43 |
package unusable for some users, a regression, something that makes |
| 44 |
the package unusable for all users, removal of a blocker, etc - |
| 45 |
roughly in increasing severity), and the other a true priority (H/M/L |
| 46 |
- which is at the discretion of the maintainer, but perhaps set |
| 47 |
initially based on guidelines in order to help them out). |
| 48 |
|
| 49 |
Rich |
Archives