• Share this article:

Bugs

Tuesday, March 21, 2006 - 22:42 by Wayne Beaton

Yesterday, I spoke with dozens of folks doing great things with Eclipse technology. One pretty common theme–one that I’ve seen repeated in far too many places–is hesitation to report bugs. Everybody gives a different reason for not reporting bugs. Some simply don’t know how. Some figure that their bugs will be ignored. Some folks actually believe that they’re not qualified to report bugs. There are other reasons; many other reasons.

The mechanics of reporting a bug is pretty easy. All bugs are reported and managed through Bugzilla (you can get here by clicking the “Bugs” link on the home page). Before you create a bug, you should probably determine if the problem you’re seeing has already been reported. If it has already been reported, you should add comments (assuming you have additional information that might be helpful). In order to create a bug (or add comments to an existing bug), you need to create a Bugzilla account. Pretty extensive help is on the Eclipse Bugzilla site.

The Eclipse project teams thrive on bugs. Erich and John spent a good chunk of their talk at EclipseCon today talking about bugs and how valuable they are to the project teams. This is how the teams communicate with each other and the community. It is part of the fabric that is Eclipse to take bugs very seriously. Erich presented an interesting statistic early in his talk: apparently on average every developer on the Eclipse project resolves one bug report every day. John pointed out that the statistic includes more than just bugs: it includes feature requests (he then lamented that Bugzilla doesn’t do a great job of distinguishing between feature requests and bugs). That’s a staggering number of bugs and a great indicator of how important these bugs are to the projects.

Is every bug that’s reported resolved to the satisfaction of the reporter? No. But they’re all looked at and (typically) commented on. Well thought out bug reports that fit well within the spirit of the project, describe the problem well, and provide enough information to consistently repeat the bug are more likely to be resolved. Code contributions in the form of test cases, patches, or additions also go a long way. In short, good bug reports are well-received.

And… we have additional motivation for you. With each milestone release of a Callisto project, we’re giving away stuff to submitters of good bug reports. If you submit a good bug report, you get a “I made Callisto a better place” t-shirt. One lucky bug submitter with each release gets an iPod. And one even luckier submitter gets an Eclipse mountain bike when Callisto is released.

The catch is that you have to submit a great bug report. But don’t worry about making a great bug report (as judged by the project’s developers and, ultimately, the PMC). Just try to make a good bug report. Greatness will follow.