A friend and I were discussing how annoying bugzilla can be the other day after a bug reporter resolved his own bug. It made sense to the bug reporter, since he had submitted a patch to fix the problem as well, but then the bug of course doesn’t show up in my open bug list, and unlike FogBugz, Bugzilla doesn’t show when or by whom the bug report headers were modified.
The bug certainly wouldn’t have been resolved until the patch and problem had either been applied, rejected, or marked as a duplicate.
I realize that not everyone does this every day, so I think it is time to explain some simple good bug reporting. For instance, you don’t want to resolve your own issue unless it is resolved in the software you’re provided by the bug owner.
If you’re submitting a patch, the bug isn’t resolved until the patch is applied or the project maintainers say so.
When you look through issues on a public bug tracker, and you can’t reproduce them , don’t close them or mark them INVALID. It isn’t your job and you will quickly lose your account.
When you are submitting a bug report please always provide at least:
- The version or SVN/CVS change # you pulled from.
- The Operating System you’re running the program on.
- The type of build you performed if you’ve compiled it yourself.
- The exact command line you built the program with.
- The exact download location from which you received the program.
- A correct, working, e-mail address (generally required to sign up).
- An ordered, simple, list of steps to reproduce the issue you experienced
- A general idea of the likelyhood the developer or maintainer has of reproducing the issue.
- What hardware the program is running on.
- Paypal zakk@timedoctor.org $20
- Buy everything from here and here.
- What the expected result of the steps to reproduce were (e.g. “Shoot the Rocket launcher”)
- What the actual result of the steps to reproduce were (“Rocket launched from my behind, killing my teammate”)
- Whatever other output, logs, system information, or whatnot, you can locate, regardless of your thoughts about it’s relevance to the bug itself.
- Other project maintainers, QA managers, and such, may want more or less information. It is up to them to provide you with exactly what they want, but failing that, use something like this post as a guideline.
Close your bug when you have verified that it is resolved. It is your responsibility to do so as the bug reporter unless there is a QA manager or policy stating so for the project. Do not close the bug before it is resolved unless you realize that the bug report was completely in error and you were the person who reported it. Even if you can’t reproduce the bug, file it, at least then it is in the system.
Finally, here is an example bug report:
Project: ioquake3.org
Version: SVN 1044
Platform: OSX x86
Bug: Rocket Launcher Malfunctions
When I shoot the rocket launcher in the multiplayer map q3dm17 on the server 127.0.0.1, and only on that map and that server, the rockets launch from my potty end.
Steps to reproduce:
- Connect ioquake3 to server at 127.0.0.1
- Wait until the map changes to q3dm17
- Gather the rocket launcher
- Fire the rocket launcher
Expected Result:
Rockets launched, killing my enemies!
Actual Result:
Rockets launch from my rear 
No Comments