Re: Bugzilla outstanding issues

[Owen Taylor <otaylor redhat com>]

Martin Baulig <martin home-of-linux org> writes:

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

And how are they going to fix it later? Guessing? 

(As a social phenomena, If you need more information on a bug, you
 must ask for that _immediately_, or you won't get a response.)

> 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 status (as below) is the right way to handle this.
 
> > 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 ?

Well, a large number of the bug reports we get are best answered with

 "Try a newer version, and if it crashes again, submit a new bug
  report."

A crash against gnome 1.0.40 with clear reproduction instructions
is worth leaving open until someone verifies that it doesn't
happen with the latest version. A random crash with 1.0.40 isn't;
but it isn't INVALID. Its a real crash, just one that we are
almost sure that has been fixed, and it isn't worth trying to
debug against 1.0.40. Thus OBSOLETE.
 
> 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.

Ah, yes, we should have the NeedInfo status (Red Hat bugzilla has
this, and it is useful)

But, for INCOMPLETE, I'm thinking more of the terminally incomplete
bugs we get a bunch of currently - just a backtrace that makes
you think that it probably was some sort of GNOME program and
nothing else.

(I think raising the bug-reporting bar is the best way to deal
with these, but still, we do get a lot of these...)

It's a lot of work to write back and say:
 
 "I need reproduction instructions to proceed further, do you 
  have any idea what you were doing when the program crashed."

And the response probably is:

 "I don't know, there was this yellow bomb on my desktop that 
  I double-clicked on and the bug report form popped up."

But even if you go through this process, closing it as 
"INVALID" is not appropriate at this point, because there
was a bug, a valid bug, there just wasn't enough information
to go on.

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

NOTABUG covers a narrow range of things within the general umbrella
of invalid. For instance, someone doesn't know to use gtk-config
and reports a bug against GTK+ because glibconfig.h is in the
wrong place.

Obviously, having 

 OBSOLETE
 INCOMPLETE
 NOTABUG
 NOTGNOME

Is more clutter than simply INVALID, and doesn't add much extra
flexibility in searching (I can't imagine really wanting to look at
all bugs in only one of these categories.) On the other hand, it
could be useful statistically, is not much more work for the developer,
and most particularly, it is more courteous than simply INVALID.

[ 
  If someone wants to come up with a better alternative to INVALID,
  that could work, but any alternative is basically going to
  mean "No Good", so it is hard to come up with a polite term
  for "No Good". 
]
 
> > 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.

Any developer who can't be bothered to be polite to bug reporters
deserves to lose their users ;-)  [ Though wth non-polite bug
reporters, a simple closure might be politer than a response ] 
 
> 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).

If the document can be sent, that's fine. [ Pre-prepared comments, so
to speak. ] But closing bugs for no apparent reason will not
get us satisfied customers.

Regards,
                                        Owen