Re: bugsquad guidelines

[Luis Villa <louie ximian com>]

On Sun, 2002-11-10 at 18:47, Malcolm Tredinnick wrote:
> Most of this I agree with, but...
> On Sun, Nov 10, 2002 at 10:50:39PM +0000, Andrew Sobala wrote:
> > -- gentoo and LFS: are you _sure_ we can just recklessly close crashers
> > on these systems? I didn't know that...
> 
> Yeah, closing them blindly is bad. Sometimes the bugs are due to our
> packages, sometimes due to the distribution. If the person provides good
> information (and provides more if needed after a NEEDINFO request), then
> ignoring them is not good (and I realise that particularly LFS leads to
> a lot of stress in trying to help them since a lot of LFS people do not
> have the experience to work with LFS in the first place; but life sucks
> a bit like that).

<sigh> Yeah. I've made comments to the effect of 'nearly all of them can
be closed on sight' but that's a _nearly_, not an all. In most cases the
correct thing is probably to NEEDINFO until good information on
everything (especially build options, like -O3 or -O9 or whatever crack
they build with) is obtained, and then reopen or close appropriately. If
they build with anything greater than -O2 that's grounds to close
immediately, period.

WRT Sam's comment- yes, we should handle crappy setups. We are
absolutely, 100%, not responsible for problems introduced by the
compiler- and we have no way of knowing if anything compiled with -03 or
above is a compiler problem or otherwise. 

> > -- crashers: in general, not a good idea to ever NEEDINFO them. NEEDINFO
> > means that the bug cannot be fixed without further information; the
> > stack trace is a very useful source of information in most cases.
> 
> This is a tricky one. But I guess the "bugsquad" pass should not
> automatically NEEDINFO these bugs. I have a fair amount of experience
> fixing bugs that just contained stack traces and in some cases it's
> possible, whereas in a lot of cases you really need the "steps to
> reproduce this bug". So probably leave them alone and let the developer
> decided whether or not they need more information.

Agreed with Malcolm. Note that I tend to disagree with Heath; people
don't just invent stack traces. The correct sequence for crashes (IMHO)
is basically:

1) check for dups; mark it a dup if it is one.
2) if the trace is obviously useless or bogus in some way, mark it
INCOMPLETE. 
3) If still open after 1&2, confirm it. It happened, whether we can
reproduce or not, and we (generally) don't know enough to know whether
or not it's useful. If it is left unconfirmed, the hackers will never
see it and be able to judge it for themselves. 
4) /explicitly/ ask the reporter for more information (if appropriate)
and /explicitly/ ask the maintainer 'maintainer, is this stack trace
useful- please close it if not.'

Andrew, FWIW, yes, the confirmed/unconfirmed situation is a bit messy,
but the one thing we should at least attempt to guarantee is that
nothing useful is in UNCONFIRMED so that maintainers can assume it is
safe to ignore that.

Anyway, great to see some discussion here. Aschwin, can you update the
draft doc appropriately?

Luis