Open-Source Bug Tracking with Bugzilla

Simplicity is the key to an easy-to-use system. Bugzilla comes set up with extensive lists of operating systems, priorities a bug can have and states a bug can be in. It is important for an efficient work flow that you adapt these to your specific needs. This is true especially for priorities, which Bugzilla calls Severities. I know no environment that requires as many priority levels as come with Bugzilla originally. Usually no more than three severities are needed: high (or showstopper) for major bugs that cause production stops or block other people from completing their work, medium for most normal bugs and low for minor issues such as typos. Any more than these cause confusion.

Similar rules apply to the state that a bug can be in. The states should reflect your normal work flow, not the other way around. A standard set of states may include New, Accepted, In Progress/Open, Resolved, Not a Bug and Tested/Completed.

These are all simple tasks, but thinking about them initially and communicating them with your teams in the early stages of rollout prevents confusion and guarantees a smooth introduction of the new tool.

To install Bugzilla, get the latest version from bugzilla.org. Although version 2.16.3 is declared as the latest stable release, I have found no problems with the many 2.17.4 installations we have running. This newer release also has many interesting extra features. You also need Perl 5.6 or higher, a running MySQL Database, minimum version 3.23.41. With a little manual tweaking, databases such as Oracle and Postgres also work well. Finally, you need a running Web server—Apache, of course, is recommended.

The installation process is pretty straightforward. After installing a number of Perl libraries and setting up a database user dedicated to Bugzilla, the installation basically consists of copying the contents of the tarball to your Web space and running the checksetup.pl script located in the main Bugzilla directory. This magic script sets up the vitals, including the administrative user and access permissions. It also creates a file named localconfig. This file's contents are self-explanatory and include, for example, the database connection settings. Be sure to install the Perl packages that are declared optional and a package called dot (part of GraphViz). These extra packages allow for enhanced graph and reporting capabilities.

While you are at it, include the collectstats.pl script, which allows for the nifty bug history graphs in your crontab. After running checksetup.pl again, you are able to access a fully functional Bugzilla in your Web browser. In the footer of the start page you should find a link entitled Edit parameters. Run through the settings on this page and set them as appropriate.

The most important settings include:

Users can create their own user accounts by clicking the New Account link at the bottom of each page, assuming they aren't logged in already. However, should you wish to create user accounts ahead of time, here is how you do it. After logging in, click the Users link at the footer of the query page and then click Add a new user. Fill out the form and click on Submit. Make sure to restrict your user's rights to reasonable access levels.

Figure 3. For instant access, new users can sign up easily and get their password by e-mail.

Figure 4. There should be clear guidelines in your teams as to how to report a bug properly. This includes giving as much information as possible to track down problems efficiently.

Figure 5. Each person involved with the issue automatically receives an e-mail notification on new bugs.

Figure 6. Processing of the issue is reflected by changes in its status in combination with meaningful comments.

In addition to adding users for each member of the team, you also may want to create an anonymous user. This can be useful for allowing external persons, such as customers using your Web site, to submit a bug without the added overhead of creating a new user account. Now is also a good time to set up your products and related components, as discussed earlier. Don't forget to insert meaningful descriptions and assign the right person to each component.

The last step is to set up the correct lists of used operating systems, bug states and priorities for the system. All of these settings can be altered and improved upon later without problems or downtime, but try to prepare as much as possible now to avoid confusion among the users and improve the smooth integration of Bugzilla in your work flow.