Bugs, and how to deal with them.

[Luis Pedro Coelho]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le Mercredi 14 Mai 2003 07:57, Nathan Murphy a écrit :
> reasoning?  I want an explicit yay or nay from the
> developers (preferably those whose fingers have been
> in the code a while) before I engage in any drastic

I don't think I qualify , especially on this list (kfm), but I will tell you 
what I do for old bugs (3.0 or before):

Get version 3.0, 3.1.0, BRANCH & HEAD on your system - with konqueror this can 
be a bit of trouble - but have different cvs checkout and just switch 
instalations, or switch users on simultaneously running Xsessions, or 
whatever. When you see an old bug report, make an honest effort to reproduce 
it on all these.
This is a bit of work to set up as a system, but if you are going to dig in on 
a lot of bug reports, then you just need to do it once.

1. Best case: you see it in 3.0 or 3.1 but neither HEAD nor BRANCH, close it 
saying so.

2. you see it fixed in HEAD, but not BRANCH. Make a comment saying so, but do 
_not_ close. This helps others who might try to tackle the problem (since it 
is a backport and not raw coding, it might be easier - also developers 
runnning cvs will be made aware that the bug still exists for BRANCH), and in 
case no one does fix it until 3.2, then the bug can be trivially closed 
(since then 3.2 will be the stable version).

3. Can reproduce all the way. Mark it so (especially if it is still 
UNCONFIRMED, but even if it isn't just a "still in BRANCH + HEAD of 14 May 
2003" will help people). Also, add any information you think might help (post 
test files, updated backtraces, etc.)

4. you don't see it at all and the bug is pre-3.0. Write a "I can't reproduce, 
can anyone? I will close with WORKSFORME if there are no further comments." 
type of comment and close a couple of weeks later if no one says anything to 
the contrary. More often than not, the automatically sent email to the bug 
reporter will trigger a response which will help. I call this a "delayed 
close."

5. you cannot reproduce at all and it's a 3.0 bug. Use your best judgement. 
Here are a couple of heuristics:

- - Does the report include a backtrace which is outdated (refers to functions 
or a call-stack which cannot happen in today's code?) as its main feature? If 
yes, then close it: even if the bug is still present, the backtrace will no 
longer help anyone and if you can not reproduce then there is a fair chance 
it is fixed. You might also use the "delayed close." if you are unsure about 
it.

- - Is the report overly vague ("konqueror crashed.", for example)? Use "delayed 
close" with specific mention that it is overly vague.

- - Is the report pretty specific and generally well written (includes a 
complete description on how to reproduce, a test case, version information, 
etc.). Say "I cannot reproduce on ...." but don't close. Consider this like a 
negative vote, when you have enough of them, you are justified in closing. 
Besides, it might trigger a response from the original reporter or someone 
else.

- - System-specific bugreports (fails to compile on Solaris x.y, for example) 
should never be closed by someone which is not on one of those systems, 
except if you can honestly say you believe the bug has been closed. For 
example, there is a CVS log saying "fix compilation on solaris" on exactly 
this issue, but noone closed the actual bugreport. I have seen this exact 
case twice. These cases are the exceptions, though.

- - You know that some work has been done on that area of the code (here you 
just need to read cvs logs not actually have written the code). Say so and 
ask for comments, don't close.

- - Does the report include a link which is stale as a test case. "Delayed 
close" unless you get a more recent test case. Something saying "konqueror 
crashes on <URL>" and <URL> points to a "404 File Not Found" will not help 
anyone. BTW, whenever you find URL to external test cases, you might upload 
them to bugzilla to avoid this problem in the future.

- - When in doubt, don't close. Add any info you might have uncovered in the 
process.

As I said, this is a complete personal view of the problem, but it is what I 
use and I think it is a good compromise between keeping old bugs forever and 
closing as much as possible.

Regards,
- -- 
Luis Pedro Coelho

"Technology does not always equal progress."
Douglas Coupland
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+wjoUGpBAvyRwXdgRAunvAJ91BW782d+Yrnz4/feN7Pju9xc/bgCgow4W
zS/uofUDbM7y/JQ755CDqEA=
=20kF
-----END PGP SIGNATURE-----