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

Re: Time before closing an unreproducible bug

On Sat, 27 Jan 2007 09:47:22 +0100
Julien Valroff <julien@kirya.net> wrote:

> Hi,
> Is there any globally accepted consensus about when closing an
> unreproducible bug?

General factors:
1. Is the bug submitter communicative?

2. Does the bug log include sufficient information?

3. Could it be architecture-specific? (i.e. are you able to test on the
same arch as the submitter?) Yes, I know Python is meant to be
architecture-neutral but so was Java . . . (Besides, this bit of
python, like many others, has to work with other programs which have
architecture-specific binaries and this might not be a bug in your
package, it may be a bug in one of those.)

4. Have you checked, carefully, that the listed dependencies are all at
the correct version for the reported distribution? This can be a source
of nasty bugs when the submitter, for whatever reason, hasn't run
apt-get update; ... upgrade recently.

> #396653[0] was opened 86 days ago, and nobody can reproduce this bug,

That, alone, is insufficient reason, IMHO.

> which was already downgraded from grave to important with the RMs'
> permission.

That's fair enough - it is a crash so a bug exists, somewhere. It may
be confined to this one installation, it might not.

I'm no Python-ite so does the backtrace show anything useful? Could
upstream handle the crash even without a reproducible method? e.g. does
the backtrace show a typical bug? I can't give a Python example (don't
know Python!) but in other languages, there are particular constructs
that are common sources of bugs - often shown up by warnings in the
buildd log.

A crash is always a bug - no matter what the cause, if a program
crashes then a genuine bug does exist, somewhere. You can't just put
your head in the sand and close the report for the sake of a good
appearance. Function is more important than appearance. This leads to
lots and lots of bugs remaining open but that's a separate problem.

> I would like to close the bug to keep the BTS as clean as possible,
> but do not want to break established rules.

Personally, I don't think that is a sufficient reason to close this
particular bug. It may well turn out to be a bug in a different package
(NFS or kernel). For this particular bug, the submitter has been
communicative and has offered to return with more test results - he
deserves at least a ping before anything happens to close this bug.
He's using amd64 - are you testing on amd64?

IMHO, unreproducible has a similar meaning to moreinfo - it is
open-ended and not suitable as a closure, particularly if the bug
report indicates a crash.


Neil Williams

Attachment: pgpAcz5f6_k2t.pgp
Description: PGP signature

Reply to: