OT choice for bug reporting systems

[jdtoronto]

Esteemed Monks,

Once again I seek the advice of my knowledgable and generous colleagues here in the monastery.

I run a consulting and contracting practice. Our principal business is the design of electronics which includes miroprocessor and microcontroller coding as well as FPGA and other VHDL design work. As a 'side-line' which is growing rather rapidly I also do some web-app and other Perl based coding.

Until now each engineer or programmer has manitained his own 'bug-tracking' for his jobs. This is no longer working. I need a centralised way of tracking bug reports.

I am aware of Bug-zilla, but I have no idea of the resources required for it. What else should I consider, what advice do any of you have to offer?

jdtoronto

[Fletch]

There's Request Tracker, which is pretty flexible (but may be a bit heavier duty than you're looking for). It's what runs the CPAN bug tracker if you want to see it in action.

[gellyfish]

Well, to keep this somewhat marginally Perl related, I think you probably would want to look at RT - it is written in Perl, not too hard to install and is used by the Perl Community.

/J\

[edan]

We use Bugzilla, and find it meets our needs quite nicely. It's pretty simple to install and set up - if I remember correctly, you'll need MySQL (freely available), perl, a bunch of modules (I think there's a bundle), and a webserver (apache does nicely). Oh, and a real OS (Linux, Solaris) - if you want to set it up on Windows, you're probably in for trouble. The installation section of the docs might be a good place to find out what it takes to install. You can probably get it up and running in a couple of hours. Good luck!

[hsinclai]

I have gotta 3rd the RT suggestion. It can be heavy or lite.. I ran it on a laptop with Pgsql for a client for months accumulating thousands of tickets without a hiccup.. it's Perl using Mason..

However RT is not explicitly tailored to software bug tracking per-se, as it would be devoid of many "fields" or "categories" one might consider de rigeur for the application, such as contained a typical looking bugzilla ..

[monsieur_champs]

There are little differences between the Bug-zilla and RT. The main ones, AFAIK, are that Bug-zilla does not have an email-based interface to update / create requests, and RT have a nice interface for this.
Also, RT offers an interface to customization and the possibility of maintaining multiple queues (for lines or families of products, for example) and Bugzilla keeps an individual bug list.

As a final consideration, Bugzilla and RT have different bug-management paradigms: Bugzilla uses "there is no bug without an owner" and RT uses "There are Requests, even if there is no person to solve them". I think RT's approach is more generic, what is a Good Thing^(TM).

In your place, I would start with RT and, if I found that this is more than I need to solve the bug-tracking problem, I would switch to Bugzilla (or any other).

[sharkey]

I've used both systems, and you have some misinformation there.

Bugzilla does have a email interface. It needed some hand-tweaking when I set it up a year or two ago, so I cannot vouch for its condition, but it is there.

Bugzilla also has an interface for customization. You can have separate products (like "queues" in RT), and you can further break them down into components. So bugzilla is more flexible there.

Bugzilla allows you to set the default bug owner by product/component. We use a fake "bug" user, and assign someone to figure who should solve the bugs.

IMHO bugzilla is more user-friendly, and allows the user to customize their own stuff more, such as how their own list of bugs is displayed.

I have not setup RT, but I suspect is may be easier, precisely because there are less customizable options. RT also has some nice built-in knowledge-base functions.

[Tii]

I agree with the latter posts on Bugzilla. We use it here (NASA Langley Research Center) for tracking bugs and enhancements. I'd give it a thumbs up.