Open-Source Bug Tracking with Bugzilla

Keep It Simple

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.

The Fun Stuff: Installation

To install Bugzilla, get the latest version from 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 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 script, which allows for the nifty bug history graphs in your crontab. After running 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:

  • maintainer: the e-mail address of the person responsible for maintaining this Bugzilla installation. The address need not be that of a valid Bugzilla account.

  • urlbase: defines the fully qualified domain name and Web server path to your Bugzilla installation.

  • whinedays: set to the number of days you want to allow a bug to remain in either the NEW or REOPENED state before notifying the responsible party that he or she has untouched new bugs. If you do not plan on using this feature, simply do not set up the whining cronjob described in the installation instructions above, or set this value to 0.

  • commenton*: each of these fields allow you to dictate which changes can pass without comment and which must be commented upon by the changer. Usually it makes sense to allow users to add themselves to the CC list, accept bugs and change the Status Whiteboard without adding comments about the reasons for the change, yet require that most other changes come with an explanation.

Adding Users, Products and Components

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.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Vermis - new open source issue tracker

Lukasz Cepowski's picture


I would like to introduce the project that I'm working on for a few months :)
Project is called Vermis (lat. bug, worm). It is an Open Source issue tracker
and project management tool for software developers and project managers that
has been created for improving quality of code, efficiency and speed of
development. Designed as a standard web application written in PHP (Zend Framework and Doctrine ORM), it can be
used on almost any platform and hosting service, including Windows, Linux and

Project is available here
The online demo is here

The long term goal is to compete with commercial products like Jira and other
open source software like Trac, Redmine, Mantis, Bugzilla etc.
Vermis is being distributed under terms of GNU General Public License, so you
can use it both in open and closed source projects.

Why Vermis exists?
- Jira has a lot of features but it is hard to use, and first of all it is a
commercial software
- Redmine needs RoR which is resource consuming
- Trac needs Python
- Bugzilla needs Perl
- Mantis, hmm i just didn't like it ;)

Why Vermis is better than the other products?
- Vermis is written in PHP and uses MySQL, which is probably the most
widespread and the cheapest web platform nowadays
- It doesn't require any additional software on a hosting server (except
mod_rewrite which is also very popular)
- Currently it has similar functionalities lika Jira
- It growns very fast :)

What Vermis already has?
- Multiple projects in one place
- Web access from any place on Earth
- Public and private projects
- Many types of issues
- Components
- Milestones
- Versioning and the history of changes
- Dynamic grids (issue navigator)
- Many user accounts
- Online registration
- Notes
- File upload
- Comments
- Progress bars
- Email notifications

What Vermis will have?
- API via SOAP or REST
- Graphical reporting
- Burndown charts
- Agile support (Scrum)
- Custom issue types, priorities, statuses, etc
- Dynamic access control list
- Automatic collecting reports from the external applications
- Wrappers for PHP, Java, C#
- many more ;)

I'm inviting to watch, test and use Vermis.
Since version 1.0 RC3 Vermis is its own bugtracker, which is available at
The latest source code you can download from
Any questions you can post at the official project's forum which is at

I'm looking forward for any feedback, comments and critique :)


How to install bugzilla in windows xp service pack-2

Nagesh.Ponnapalli's picture

please tell me How to install bugzilla in windows xp service pack-2

Offline client for Bugzilla

Anonymous's picture

Bugzilla now has a desktop client, Deskzilla, that is able to preload bugs and work offline with later synchronization. It's not developed by Mozilla and though it is a commercial software, it is available for open source projects for free. Screenshots, available on Deskzilla site, show a linux kernel bugs neatly laid out in categories. I wonder when they will have charts and reporting...

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture

Bugzilla is pretty hard to config/custimize. We use TestTrack Pro by Seapine Software

Another simple option

Jason G.'s picture

I am also on the i-want-something-easier wing. i stumbled upon BugWiki (, and that turned out to be the right thing for me. No install, just a sign-up. Simple to learn, too.

Someone posting fake bugwiki reviews?

Anonymous's picture

Is it just me or is Jason G a BugWiki employee. I have been researching some bug tracking tools recently and everywhere I see, there are some recent comments about how good bugwiki is (twitter, some bug tracker comparisons etc). I look at bugwiki and it's no better than scribbling down stuff in a spreadsheet. I am not saying it's bad (everything has it's uses), but persistent comments stating how great bugwiki is, is pretty darn suspicious. Especially on a post that is a nearly a year old?

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture

I looked at Bugzilla for my organization, however it didn't do enough in the way of time-tracking and groupware for it to be useful for a single company or a consultant. Instead, I created an enhanced version of Outreach Project Tool (orginally from an Austrian firm) that did everything I needed and more:

Check out the project page or the try the demo site.

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture

OPT looks nice, though I hadn't stumbled on it ~6 months ago when doing my review. I looked at about 2 dozen; propriatory and OSS, commercial and not. That doesn't even count the ones I rejected without doing the full installation and analysis.

The last time I went through finding an acceptable issue/defect tracker, I had one person perk up; "Great! I already have one written in Access. I can make any changes you want." (There were a few of these already in use by 1 or 2 projects here and there also.)

Ack! No, I've done that too. Mine was even used to track about 800 test cases plus defects/enhancements for a ~30 million dollar project and I will *never* do that again. 'When all you have is a hammer...look around and find other tools!'

Even if you are clever, chances are someone else has a more appropriate tool that almost does the same thing. There's only so many things that you can do with this stuff before turning it into another category of app.

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture

If you're not a huge fan of Bugzilla (I'm not too keen on the way it's been written), it's also worth considering RT from

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture

One of the really bad things about RT is how

- You enter a Request in RT, people receive an email.
- If people want to add a comment to a Request, they respond to the original email. Usually they'll include the body of the original message in the email.
- If you go back to the RT web interface, you will now have the original Request, and the new response which includes the original message in the email.

Since many conversations will take place via email, and including the body of the previous messages in the email body is a standard practic, this leads to a very very messy and confusing list of bugs in RT.

It would be great if RT would strip the old messages from the emails.

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture

I couldn't get it to be adopted...even found a company that would ship a custom system and support it. The reason it was rejected? Looks. "It has to be pretty; the executives need that otherwise it won't fly." I understand that if they are the ones deciding on what tool to choose...they only have so much time...yet....

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture

I don't see why one would need support. I installed Bugzilla, Apache, and MySQL on a Windows NT box at work.

Once I did the initial manual patching to get Bugzilla to work on NT, I haven't touched it since. It has run about a year so far with no problems.
I also changed some of the text to say "My Company - Issue Tracking System" instead of Bugzilla and "zarro boogs" to "no bugs".

There was no official need identified at work, but eventually it became a standard part of our process.

Go work for a small company. They don't spend 4 months of meetings making decisions.

Re: Open-Source Bug Tracking with Bugzilla

Anonymous's picture
    I don't see why one would need support.

Here's the conversation (in a nut shell) that I went through over Mozilla;

  • Exec: We need something that's ready to go.
  • Me: But the customization is not too bad, and there are commercial companies that can do it.
  • Exec: We don't have the budget.
  • Me: The licence costs for the commercial releases we are looking at are $15,000; base. We can do the work for less and pocket the difference; Bugzilla doesn't cost a thing in licencing.
  • Exec: They don't need to be custimized, and they look good out of the box. Sorry, Bugzilla is not an option because of that.
  • Me: When the other products are rolled out to the whole company, it'll cost much much more.
  • Exec: That's fine; we only have a few people that have to use it, mostly mid-managers and above.

    While this is not entirely true (the commercial app did need customization and the information would be entered and searched mainly by non-managers or lower-level managers), I could not press the issue without causing friction so I dropped it. The executive made up his mind, and short of finding a 2 second patch that made Bugzilla match every function and the look of the commercial closed apps, I was not going to get any traction.

  • Re: Open-Source Bug Tracking with Bugzilla

    Anonymous's picture

    You must work at my company ;)

    Re: Open-Source Bug Tracking with Bugzilla

    Anonymous's picture
      You must work at my company ;)


    I've worked at many, and rarely can I get people to listen...or more importantly, act or let me do the right thing. The executive I'm (roughly) quoting is actually a real smart guy and does understand many issues. I'm still puzzled why he took the system that he knew already...except that he knew it already. Human psychology is interesting at times.

    Re: Open-Source Bug Tracking with Bugzilla

    Anonymous's picture

    er...sorry. Bugzilla, not Mozilla. (Though come to think of it, the conversations can be similar.)

    Re: Open-Source Bug Tracking with Bugzilla

    Anonymous's picture

    Silly really - I'm sure they'll find some pretty looking solution that doesnt work then!

    Re: Open-Source Bug Tracking with Bugzilla

    Anonymous's picture

    Any comments on Scarab?

    To reply to your comments in the meantime: there are plenty of tools like Bugzilla. Not exactly, but similar enough that people won't care either way.

    The problem is that people are creatures of habit and like to pick sides early. Even though the budget might not allow for an expensive tool, people who want "a name brand" or "this software; I've used it, it works" will find some way to buy it.

    Case in point: ClearQuest. Horrid if not configured. OK if properly configured. At one company: the budget for the software (and the other Rational tools) soaked up any money for customization and maintenance. The result: Nobody wanted to use it, so they didn't, and people ended up rolling their own issue trackers or purchasing additional tools to fill specific needs. No _1_ tool is in consistant use, and they can't share data easily.

    Most of these tools can be modified heavily. The main concern is if the maintenance is acceptable and can the data be moved out of the system easily (no lockin).

    Bugzilla can output to other systems -- if you configure it to do so. Yet, it is better to have one tool and eliminate the duplication.

    Attempting to get people to use a Wiki also causes problems, mostly because it's a good tool that most aren't familar with.