What issue tracking system is best for you?

A review of Bugzilla, Trac, and JIRA

It is an eternal truth that newly written software packages will contain bugs. To track bugs, many organizations still rely on Word documents and Excel spreadsheets, but these tactics are inefficient and error-prone to say the least. A good automated issue-tracking solution should streamline the process of raising, managing and fixing issues.

In this story, we look at three issue-tracking solutions: Bugzilla, Trac, and JIRA. According to some unofficial polling done by yours truly (see Resources), these products appear to be among the most widely used issue-tracking tools in the Java community today.

Bugzilla is probably the most well-known of the open source issue-tracking solutions and is used by many high-profile open source projects such as Mozilla, Apache and Eclipse. It is a mature, feature-rich open source issue-management solution well-adapted for use in large projects.

Trac is another open source issue-tracking system, but with a different approach. Trac is a lightweight, minimalistic solution, designed to allow effective issue management with as little overhead as possible. It also boasts excellent integration with Subversion. And JIRA is a well-regarded commercial product widely used in the Java community, especially among open source products.

Bugzilla: The original Web-based issue-management solution

Bugzilla is probably the most well-known of the open source issue-management tools. It is used on many open source projects such as Mozilla, Eclipse, and many Linux distributions, and is well-adapted to large, open projects.

Bugzilla is typically installed in a Unix or Linux environment, though it can work on Windows with a bit of extra work. Bugzilla runs on Perl, and uses either MySQL or PostgreSQL as a backing database. You also need a Web server: Apache is the typical choice. Installation occurs from the command line and basically involves installing all the necessary Perl modules, setting up the database, and scheduling external Perl scripts to collect data for bug graphs and to send notifications. The installation process is long and involved and often full of surprises; only the bravest and most intrepid will come through a full Bugzilla installation unscathed.

Bugzilla is powerful and flexible, and fits well into a multiproject environment. You can manage multiple products, optionally grouping related projects into "Classifications." And, for a particular product, you can define components. To assist project management and quality assurance, you can define versions and development milestones and release versions.

Because of its origins as an issue-management system for open source projects, Bugzilla is, by default, quite open about security: users can usually create an account themselves and create and access bugs for any project. If need be, however, you can restrict user rights to certain projects or create groups so that certain products or bugs can only be seen by certain people.

Bugzilla Web sites are usually easy to recognize. In its standard form, Bugzilla has arguably one of the ugliest and most convoluted Web sites. However, it is functional.

As you might expect from a product that manages systems containing literally hundreds of thousands of bugs, Bugzilla has powerful, if not particularly user friendly, search features. You can search for existing issues using either a simple and convenient keyword-based search (with optional filtering by product or by status), or by using the more sophisticated Advanced Search, where you can filter on virtually any field in the database (see Figure 1).

Figure 1. The Advanced Search in the Eclipse Bugzilla database. Click on thumbnail to view full-sized image.

Although the interface is rudimentary and lacks many of the niceties of more recent Web sites, entering a new issue in Bugzilla is relatively straightforward. After selecting the buggy product, you arrive at the bug details screen (see Figure 2). Out of the numerous fields you'll see, only the Summary and Component fields are actually mandatory. You will usually also provide other details, such as a version number (the version of the product in which the bug was found), severity of bug, platform, a target milestone, and so on. You can assign a bug directly to a developer, if you know who you are working with, or just wait for it to be picked up by some willing soul. If you can't remember the definitions of the various severity levels or how to use a particular field, convenient hyperlinks about the field names display the appropriate help pages. You can also use attachments to add screen shots or the like.

Figure 2. Entering a new bug. Click on thumbnail to view full-sized image.

Bugzilla supports a fairly complete, albeit hard-coded workflow model (see Figure 3). The typical life of a bug goes something like this: A tester (or user) creates a new bug. New bugs are created either as unconfirmed, new, or assigned. Typically, a developer will accept a bug (or assign it to someone else). Once the developer has corrected the bug, he or she can mark it as resolved, specifying how it was resolved: fixed, invalid (not a bug), duplicate, won't fix, and the (in)famous "works for me." A resolved bug isn't officially closed until someone from QA (quality assurance) checks it out. Once QA has confirmed the correction, the bug becomes verified. It remains in this state until the product release containing the fix actually ships, at which point, it is closed. Although this workflow model cannot be customized in Bugzilla, it usually proves sufficient for most organizations.

Figure 3. The Bugzilla life cycle model (from the Bugzilla documentation). Click on thumbnail to view full-sized image.

Bugzilla notifies users of any new or updated bugs by e-mail.

Bugzilla also supports a system of votes, in which users can vote for issues or features they wish to see implemented. If enough votes are made for a particular issue, it will pass automatically from "Unconfirmed" to "New." This functionality proves useful for large projects or projects with active user bases who participate in the development process.

Bugzilla provides some reporting and charting features. You can generate tables, and simple bar or pie charts using a screen similar to the Advanced Search screen (see Figure 4). To display graphs of data over time, you need to set up special "data sets" that collect the data you want on a regular basis.

Figure 4. A chart generated by Bugzilla. Click on thumbnail to view full-sized image.

Bugzilla is a tried-and-true solution that supports large projects and user bases. Its workflow features are more than sufficient for most organizations. On the downside, Bugzilla is particularly complicated to install and maintain, and the user interface wouldn't win any prizes for design or usability. Its reporting features will do the job, though they are not particularly user friendly.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform