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.

The Fun Stuff: Installation

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:

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.

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.

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
more.

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 :)

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...

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?

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:

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.

- 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.

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....

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.

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.

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.

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.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.