Issue #20 June 2006

If it's not in Bugzilla, it's not a bug


-->

"If it's not in Bugzilla, it's not a bug." A common statement heard in the halls of engineering or in IRC chat rooms here at Red Hat. And it's not as far from the truth as it may seem.

All software has at least some bugs in it; anyone who says differently is merely in denial. Software shipped by Red Hat is unfortunately no exception. The complexity of the hardware Red Hat has to support and the millions of lines of code that makes up a Linux distribution accounts in part for the number of bugs that are reported. Red Hat is dedicated to providing fixes to its customers efficiently and in a timely manner.

Without the use of popular open source tracking tools like Bugzilla, it would be virtually impossible for developers to keep them under control. Bugs can be reported in all types of ways, from mailing lists to phone calls. Without a structured way to collect information, it would be easy to become quickly overwhelmed.

Bugzilla also allows us to organize the bug reports in ways that fit well with our internal processes. It is a tool used by almost every department in the engineering organization. Because it is open source, alterations can be made to make it fit our needs even better.

Red Hat's port of Bugzilla is also used for non-bug-related functions. We use it to track features for upcoming releases and to catalog hardware certified for Red Hat solutions. So when someone reports that they have found a bug or would like to see a new feature added, the first question our engineers always ask is, "Is it in Bugzilla?"

The tracking system known as Bugzilla originally came into existence around 1998. It was written by a small group of then-Netscape employees for their bug-tracking use. Originally written in TCL, it was later rewritten in Perl in hopes of garnering more community support.

Red Hat adopted it shortly after the TCL to Perl transition, and has been using it ever since. Its popularity has grown, and Bugzilla is now being used by numerous open source projects such as the Mozilla web browser, the Apache web server, and the GNOME desktop project. It is relied on by major corporations such as Novell and NASA.

Part of the reason for its rapid growth are features that were previously available only from expensive commercial tracking systems. These advanced features include email notifications, attachments, prioritization, advanced querying, and others.

Bugzilla originally used the MySQL database as its backend. Recently, support for PostgreSQL has been added--and other databases are in the works as well. Bugzilla has a very active developer community, and new releases (and exciting new features) are appearing more frequently. The Mozilla organization normally adopts the latest code early. Given the huge amount of traffic their system receives, problems are normally discovered and stomped out quickly.

For more information on where the Bugzilla project is heading and a better description of features that may be helpful for your tracking needs, check out http://www.bugzilla.org.

One of the things that users can do to ensure a speedy resolution to their defect is to properly submit a good bug report. Many times we receive reports that say, "I try to run program X and it doesn't work". Because there are so many possibilities that could make something "not work," a busy developer has to request more detail from the reporter, slowing resolution. Developers are forced to mark the report as "WORKSFORME" if they cannot get more information. This just slows down the path to solution and causes frustration on both ends. The more effectively you report a bug, the more likely a developer will actually be able to fix it.

Here are some simple pointers that will have you on your way to being an expert bug reporter and will help us make our software even more stable and robust.

Search previously reported bugs for your problem using the Bugzilla query pages.
Before submitting a new bug, you should first check the frequently reported bugs page to see if your defect is already known. If so, you may want to read through the information given and add comments if you have more data that would be useful in reproducing the problem. You may also glean more information about your problem here.

If you don't see it in the frequent bugs list, it may still have been reported. You can search Bugzilla's entire database using the simplified query page. Type a few key words in the Summary and Comments text fields. Check out the Advanced query page for more detailed search options.

Make sure to file the bug under the proper product and component.
After searching for your defect without success, you are ready to create your report. Red Hat's Bugzilla is divided at the top level into products that we ship (like Red® Hat Enterprise Linux®) and projects we support (like the Fedora™ Project). From the initial bug entry page you will need to select your product category. For Fedora Core related bugs you would naturally select 'Fedora Core.' There are also options for 'Red Hat Enterprise Linux,' 'Fedora Extras' (for the Fedora add-on packages), and even 'Bugzilla' (for bugs related to Red Hat's Bugzilla itself).

You will also need to select your component and version. For distribution-related bugs for the project 'Fedora Core,' the components are the names of the source rpms that make up the distribution. One way you can determine the proper source rpm is to run the following from the command line on your system:

rpm -qf /path/to/offending/executable  (ie. rpm -qf /bin/ls)

and then

rpm -qi <rpm_package> (ie. rpm -qi coreutils)

to find the name of the source rpm that the package is derived from. In the previous example, it was "coreutils."

Lastly, the version is normally the version of your distribution, such as "4" for Red Hat Enterprise Linux or "fc5" for the latest version of Fedora Core.

Note
If you are running an older version, updating to the most recent release will sometimes fix your problem. Try reproducing the problem on the latest version, either by upgrading your system or testing it on a friend's system.

Give detailed information about your bug or feature request.
A good summary will go a long way towards getting your bug noticed. A useful summary might be "Graphic installer fails with XIO: fatal IO error 104." "Software fails" or "install problem" would not be good examples of a summary.

Next, you will want to describe the issue in detail in the Description field. List the exact steps it takes to reproduce the issue and how often it occurs. Include information on the expected results and the actual results. Give the version number of the software you are using. If you know which rpm package contains the problem file, then simply provide the version and release number from the results of 'rpm -qi' (as shown earlier) for that package. If you have any links such as mailing list posts or URLs to screenshots, this would also be a good place to include them. Bugzilla will automatically hyperlink them when people view the report later.

Attach large amounts of text to the report instead of posting as a comment.
Frequently defects can best be described by passing along log files such as /var/log/messages containing the system errors or the Xorg configuration file that is the cause of a failing desktop. Searching through pages of this information in the main bug view is time-consuming, and critical information could be missed. Bugzilla has support for attaching files of almost any type to a report without cluttering up the page. A developer can easily download the information to their own workstation to debug the problem. Attaching screen shots of a failing application is also useful.

Don't forget to keep an eye out for emails from Bugzilla concerning your report.
Bugzilla will send an email notification for just about every change made to a bug report: status changes, new comments, attachments, etc. Sometimes the notification is from a developer asking for additional information like hardware data, log files, or configuration files. If the reporter neglects to provide further information when needed, the developer may be unable to replicate the problem. The developer may have to close the report and the user's problem will not get solved. So make sure to keep tabs on your reports.

No login required. Want to see your comments in print? Send a letter to the editor.

As long as people write software, their will always be bugs to report, open source software included. As long as there are bugs there will always be a need for quality tracking software like Bugzilla. Bugzilla currently works well for Red Hat, and for many other large projects. Looking at the new features coming down the pipe, I believe it will continue to be a useful tool well into the future.

About the authors

David Lawrence has been with Red Hat for over eight years working in Quality Assurance. He is the lead developer on Red Hat's version of Bugzilla and helps with development on testing automation tools. He has represented Red Hat at numerous tradeshows and community events, and traveled the country on the 2002 Red Hat Road Tour.