NEEDINFO about NEEDINFO

[Chris Shoemaker]

On Thu, Apr 13, 2006 at 10:41:26AM +0200, Christian Stimming wrote:
> Hi,
> 
> (FYI: I'm out of town and away from emails until next week, April 18th)
> 
> Am Mittwoch, 12. April 2006 17:35 schrieb Chris Shoemaker:
> >         One problem I have with the current use is that it doesn't
> > seem to work well with bugzilla's default reports.  Bugzilla treats
> > NEEDINFO as "on ice", effectively resolved, so the bug won't likely
> > get any attention from anyone not already on the cc list for the bug.
> 
> Actually that statement strongly depends on the way how you are using 
> bugzilla. Indeed all bug queries that can be reached from  
> http://bugzilla.gnome.org/browse.cgi?product=GnuCash will completely ignore 
> NEEDINFO ones. However 
> http://bugzilla.gnome.org/page.cgi?id=reports.html lists a query "NEEDINFO 
> reports which have been updated" which will list exactly those, so there 
> *are* ways in which these bugs will get some attention. And as a third way of 
> using bugzilla, everyone can simply bookmark or store a particular query that 
> includes the NEEDINFO bugs as well. (I happen to use that third way, so when 
> I browse through the gnucash bugs, the NEEDINFO ones are listed for me as 
> well.)

True.  I also use a "needinfo" saved report.  Browsing that for a few
weeks is actually what prompted my email.

> > 1) Labeling a bug NEEDINFO should mean "this bug is INVALID or
> > INCOMPLETE without more info."
> >
> > This implies that NEEDINFO means "we really NEED more info in order
> > for this bug report to be any use at all", not simply "we WANT more
> > info because it sure would help."
> 
> Yes. Absolutely.
> 
> >   Let me amend my definition: NEEDINFO is for bugs that, in
> > the absence of additional info, would still be resolved anyway, either
> > as INCOMPLETE, INVALID, or, as Derek points out, even FIXED.
> > 
> > I think the usage you describe is the intended one: for bugs you don't
> > want to look at anymore (and don't want any other dev to have to look
> > at anymore).
> 
> Yes.
> 
> >   1a) Stack traces with debugging symbols are always useful, even if
> > the reporter doesn't know what they were doing when it occurred.
> > These shouldn't be marked NEEDINFO.
> 
> No, I don't agree in general. For example, if the bug report doesn't mention 
> the gnucash version (1.8? SVN?), then the stack trace can be from whatever 
> gnucash version has been released. In those cases a stack trace by itself is 
> IMHO not at all useful, and unless there has been more info added, the report 
> will be closed as INVALID.

I disagree.  The stack trace contains a lot of useful information.
Even when no version is given, the file date and the stack trace
itself often constrain the possible version narrowly.  Of course we
should ask for version info, but a stack trace is a valid and very
useful bug report by itself.  I came across two cases where a
beautiful stack trace was sitting unnoticed (by me, at least) in
NEEDINFO.  Finally noticing it significantly improved my understanding
of other, similar stack traces.  In one of those cases, noticing it
sooner would have saved me some time.

Interpreting a stack trace with no version information is more work,
(although it's made easier by trac) but once the work is done, it's
just as valuable as a report _with_ version information.

> >   1b) Bugs with reproduction instructions are useful unless you know
> > that the instructions don't work.  These shouldn't be marked NEEDINFO.
> 
> Also, I wouldn't agree in general. As you might have noticed, my primary 
> NEEDINFO question is for the exact gnucash version -- if this is unknown and 
> the reproduction instructions don't obviously imply a particular version, 
> then the bug is IMHO INCOMPLETE unless there is more information.

Well, I think asking for the version is exactly the right thing to do,
but I disagree about marking it NEEDINFO.  This practice has resulted
in real bugs that don't report a version but do provide reproduction
instructions eventually being closed as INVALID - even when the
instructions are easily verifiable and the bug is still present in
svn.  IMO, this is clearly a process failure.

> > 2) Whoever labels a bug NEEDINFO is agreeing to notice when the
> > requested info has been provided and to ensure the bug is relabeled
> > appropriately.  
> 
> Yes.
> 
> > Practically, that means joining the cc list. 
> 
> No. Depends on the way you are using bugzilla. If you use stored queries that 
> wil show the NEEDINFO bugs as well, you don't have to be on the cc list to 
> watch them.

ISTM, that method could work but would require a little extra
vigilence.  My observation has been that every time a NEEDINFO bug was
left in NEEDINFO after the requested info was provided, the person who
marked it NEEDINFO wasn't on the cc list.  OTOH, I don't have any
insight into how often NEEDINFOs are correctly relabeled by people not
on the cc list, so I have no idea what the slip-through rate is.

I think we can leave it as a recommendation to either a) join the cc
list or b) use a sufficiently rigorous alternative to notice newly
provided info.

> > 3) We should go through the current NEEDINFO bugs and if they're
> > really useless as-is, we can either leave them as NEEDINFO or close
> > them.  If they're not useless, we can relabel them as UNCONFIRMED or
> > NEW or something else.
> >
> >   3a) The implication is that bugs currently marked NEEDINFO need to
> > be re-evaluated for usefulness and that the bar for closing them is
> > not necessarily any lower than for UNCONFIRMED bugs.  But, in the
> > future, NEEDINFO would mean that the bug has already been deemed
> > useless without more info.
> 
> Yes.
> 
> I'd suggest adding the outcome of this discussion to the wiki, 
> http://wiki.gnucash.org/wiki/Bugzilla or similar. Thanks for clarifying this 
> issue.

And thanks for all you bug-triage work.  I'll see what I can put on
the wiki.

-chris

> 
> Christian