| 1 |
On Sat, 24 Mar 2007 14:48:25 -0400 |
| 2 |
Michael Cummings <mcummings@g.o> wrote: |
| 3 |
|
| 4 |
> On Sat, Mar 24, 2007 at 06:34:21PM +0100, Kevin F. Quinn wrote: |
| 5 |
> > People reporting bugs often get annoyed when their bug is marked |
| 6 |
> > INVALID; especially when they're relatively new to the Gentoo |
| 7 |
> > Experience. We've all seen it many times, I'm sure. |
| 8 |
> > |
| 9 |
> But sometimes, just sometimes, the bugs are absolutely 100% invalid. |
| 10 |
> "Emerging nano broke my apache" (random fake example with two |
| 11 |
> unrelated packages)(or...are they...?) |
| 12 |
|
| 13 |
Well, if someone raises a bug, they have an issue. They may not |
| 14 |
understand it properly, and may frequently mis-diagnose it, but there's |
| 15 |
still an issue for them. To take your example, "emerge nano broke my |
| 16 |
apache" actually implies that apache isn't working properly for the |
| 17 |
reporter - just because they incorrectly assign blame to an emerge of |
| 18 |
nano doesn't mean everything is peachy. As the details are eked out of |
| 19 |
the reporter, the summary may become "ssl support in apache broken with |
| 20 |
openssl-1.2.3.4", IYSWIM. We shouldn't be closing bugs as INVALID |
| 21 |
just because the original reporter mis-diagnosed the problem. |
| 22 |
|
| 23 |
There are cases where people raise a bug because they've mis-understood |
| 24 |
something and they don't realise it's behaving correctly - i.e. the |
| 25 |
behaviour they are complaining about is actually as-designed expected |
| 26 |
behaviour. But even then, the user had an issue - resolved by |
| 27 |
the explanation, even if the outcome is no change to anything. |
| 28 |
Closing it INVALID comes across too often as "oh you're so stupid to |
| 29 |
raise this as a bug" and there's no need for that to happen, imo. |
| 30 |
NOTABUG would do well enough in that sort of case I suppose, but |
| 31 |
there's still an overtone of "you shouldn't have raised this" to it. |
| 32 |
|
| 33 |
> More important is to explain |
| 34 |
> to the user *why* it is invalid, and leave it open to them to argue |
| 35 |
> and reopen the bug. Better communication, |
| 36 |
|
| 37 |
Certainly good explanations as to why a bug is being closed are to be |
| 38 |
encouraged. My issue isn't with that - it's with the way that the |
| 39 |
marking INVALID is perceived, when there's no need to be so harsh. |
| 40 |
|
| 41 |
> not more convoluted closure |
| 42 |
> flags, is the solution. IMHO. You know. Word. |
| 43 |
|
| 44 |
The idea was to _replace_ INVALID with a less provocative name, not |
| 45 |
add more closure flags. I certainly agree that we don't need more |
| 46 |
closure flags. |
| 47 |
|
| 48 |
-- |
| 49 |
Kevin F. Quinn |
Archives