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 ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpAcz5f6_k2t.pgp
Description: PGP signature