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:

1. The version or SVN/CVS change # you pulled from.
2. The Operating System you’re running the program on.
3. The type of build you performed if you’ve compiled it yourself.
4. The exact command line you built the program with.
5. The exact download location from which you received the program.
6. A correct, working, e-mail address (generally required to sign up).
7. An ordered, simple, list of steps to reproduce the issue you experienced
8. A general idea of the likelyhood the developer or maintainer has of reproducing the issue.
9. What hardware the program is running on.
10. Paypal zakk@timedoctor.org $20
11. Buy everything from here and here.
12. What the expected result of the steps to reproduce were (e.g. “Shoot the Rocket launcher”)
13. What the actual result of the steps to reproduce were (“Rocket launched from my behind, killing my teammate”)
14. Whatever other output, logs, system information, or whatnot, you can locate, regardless of your thoughts about it’s relevance to the bug itself.
15. 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 behind my character.

Steps to reproduce:

1. Connect ioquake3 to server at 127.0.0.1
2. Wait until the map changes to q3dm17
3. Gather the rocket launcher
4. Fire the rocket launcher

Expected Result:
Rockets launched, killing my enemies!

Actual Result:
Rockets launch on the opposite side of the player’s viewport.

Anyway, tonight my Bugzilla sends me the usual:

You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugzilla.icculus.org/) that require
attention.

All of these bugs are in the NEW state, and have not been touched
in 7 days or more. You need to take a look at them, and
decide on an initial action.

Et cetera, finally it gives me the url to check out what bugs are in the NEW state. Go on, click the link, I haven’t changed any bugs today.

For those not here today, there aren’t any bugs in the NEW state. This is annoying.

You’d be right.
Some people like it though, and since it is such a popular product, why do they like it?

Well, I’m a lazy man, so I’ll go with another ordered list to explain:

1. Support, when you pay for it, you get it. I’ve never had to use it, but it is probably pretty good. They’ll even sell you a book if you can’t figure it out. Bugzilla obviously only has free support and possibly somebody will sell you some if you try hard. Not really the same thing. You can also buy FogBugz without support though, which is hilarious when they’re charging a thousand dollars for ten developers.
2. Joel Spolsky. He writes a blog called Joel on Software, you’ve probably heard of it. Some people trust what he makes because of it. I certainly like some of the ideas he espouses in that blog. He also has some books out, et cetera. This all takes you around back to his software if you are in a position to make purchasing decisions for your company.
3. Consistent form and functionality. If you’ve ever used Gnome, then tried a newer major version, you’ll notice that they contain major changes to both form and functionality. This isn’t even half as bad as some other open-source projects, if you’re lucky enough to even get updates…
4. Works pretty much out of the box on three platforms, as long as you’ve paid for each or are willing to go through the support hoops (gotta have a paid support contract to switch, too.)
5. FogBugz Screenshot, yeah it isn’t really perfect, but if it works, it works.
6. Security through obscurity, FogBugz is not open-source software, therefore it is less likely to have security bugz found by h4x0rz. Which is also why RMS is holding that sign:

There are lots of good reasons to not like Joel Spolsky’s take on web bug management tools, and while the above screenshot is not entirely valid, other good reasons do exist:

1. If you add one user/seat over your paid limit, it (until you delete a user or buy more user licenses) disables every user. It even logs users out, and then taunts them with a message to buy more licenses when the user tries to log in again. Real friendly like.
2. Not one free test case tool works with FogBugz beyond linking to the bugs. Obviously there are significant barriers to them doing so, but seeing as many of them work with Bugzilla, we can count this against FogBugz.
3. While the screenshot tool depicted failing above is good when it works, when it doesn’t, it fails miserably and distracts you from the task at hand – reporting bugs with your defect tracking softare. I’ve had it display the login page for FogBugz (with the latest version) numerous times.
4. (This is wrong, see the comments, thanks for the correction) At least with open-source software I can have a chance at fixing the bugs myself.
5. You’re not in control of the software at all. They recently launched their major upgrade with a movie depicting how awesomely web 2.0 they are. Great guys, you’ve got ajax and a few usability improvements, did this really neccessitate a major number increase?
6. Go search for “bugzilla” on Google. Go on, I’ll wait…
7. Okay, back with me? Note the ad if you don’t have customize google installed. Yeah, FogBugz is advertising on Google AdWords with anti-Bugzilla propaganda. Real professional.
8. To add something to a case it takes two clicks. You have to click on a bug, and then click again to edit.