Re: Bugzilla outstanding issues



Owen Taylor <otaylor redhat com> writes:

> Hmmm, I think INVALID is also too pejorative - or at least for
> everything that Martin probably was lumping here.

Well, my idea with this keyword was that you can use it regardless of the
state of this bug (ie. you can flag it `trash' but still have it ASSIGNED
to someone).

Maybe we should call this `less-important' or something like this which
doesn't sound as rude as `trash' to the reporter.

Basically my idea was that a developer should have a way to mark bugs such
as a core dump of some unidentified RH 6.1 app without any other description
as `trash' and then exclude them in his bug list so he can concentrate on
fixing the other bugs but still maybe fix it later.

Here also comes a `waiting' keyword in mind which a developer can set to such
a bug if he wants to ask the submitter for more information (but keep it
distinct from `help-wanted' which should be reserved for more "valuable" bug
reports).

> A Netscape crash bug report is possibly INVALID (but a bug, even if it
> isn't _our_ bug), but what about a backtrace of some unidentified
> GNOME app from Red Hat 6.1 ... that's not an invalid bug. Sure, its
> not a useful bug report, but the person has a valid problem with
> GNOME.

Such a bug can then for instance become INVALID after it had `waiting' set
for more then a month (developer asked submitter for more information but
didn't get any reply and thus cannot fix the bug).

> Having separate resolutions NOTGNOME/INCOMPLETE/OBSOLETE is quite
> possibly overkill, but unless we stem the tied of bugs falling into
> these categories, quite possibly useful.

Well, I think anything which is not a GNOME bug can just be flagged as
INVALID (if I understand this correctly, you can provide a comment when
doing so which will be sent to the submitter - so you can tell him that it
is not a GNOME bug so he knows that he should submit it somewhere else).

I don't know what you mean with OBSOLETE - either the bug is INVALID or
a duplicate of an already FIXED one or do I miss something ?

For INCOMPLETE, I don't think it makes so much sense to have this as a bug
state instead of a keyword - as long as the developer is still waiting to
get more information from the submitter, the bug is ASSIGNED to him and when
he "timed out" waiting he needs to decide what to do with the bug. He can
then either mark it as INVALID if he really can't fix it without more info
or set it to WONTFIX/LATER/REMIND.

> [ Actually, Red Hat uses NOTABUG instead of INVALID, which is
>   marginally more polite, but less general ]

But INVALID is more accurate than NOTABUG - a Linux kernel panic _is_ a bug,
but not a GNOME bug and INVALID for the GNOME bugtracker.

> Otherwise, we need some nice, non-pejorative term that covers
> all of these situations, and then let people know with the comment
> what the situation is. 
> 
> The worst possibly thing to happen is that someone's computer
> crashes, they write up a few paragraphs in frustration, and then
> they get an email notification a few days later:
> 
>  - STATUS: UNCONFIRMED
>  + STATUS: RESOLVED
>  + RESOLVED: INVALID
> 
> We also should think about canned replies for bug reports that
> aren't about GNOME telling the reporter where they should go to
> report the bug.

Good idea, but I think we shouldn't use these configuration options
which force people to provide comments - it's way better to get such
a STATUS/RESOLVED diff back than a pissed "go a way" or "you idiot"
if some developer gets angry because he needs to write a reply.

It shouldn't be such a big problem to "just close" such bugs if there's
a document somewhere which tells people why (and such a document can
for instance be sent with the mail).

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]