Bug Tracking Database Systems?

Jeremy asks: "I am looking into changing our bug tracking database. We are using Gnats for the time being, and it doesn't easily offer information that will show statistical trends such as the number of bugs for each week over the last 10 weeks, or the number of bugs each developer has fixed for each week over the last 10 weeks, and so forth. What, in you opinion, is one of the best bug tracking software in the open source world?"

sourceforge

[darthpenguin]

Sourceforge [soureforge.net] seems to have a nice bug tracking feature, where the severity of each bug is described, who it is assigned to to be fixed, and other info about it. It could probably do something like you want pretty easily, but I haven't really messed around with it. If it's really important, I think the sourceforge code is open source, so you could build on to the existing bug tracking features.

Anyways, good luck!

-mdek.net [mdek.net]

jitterbug and bugzilla

[faster]

Jitterbug [samba.org] is simple and fast for reasonably small bug lists, but its reporting sucks hard.

Bugzilla [mozilla.org], OTOH, is more full-featured (too full-featured for most small dev groups, IMHO) and uses a SQL database. So you could theoretically run just about any report you like. I don't think it records all the bug dates you'd need for the reports you mentioned, but that's a relatively trivial patch.

The link is pr0n but not a goatse.cx link ...

[RedDirt]

*sigh* I hate Javascript bombs.

Scarab

[msuzio]

The Scarab [tigris.org] project is a fairly interesting effort to create a good bug tracker. This is from a group who used Bugzilla as a tool, so i think they saw the opportunity to observe what that did right and wrong.
I've used Bugzilla a lot, and it's OK, but it is far from perfect. It started out as a very ad-hoc tool, and has evolved organically from there (and it shows). I wouldn't use it by preference, but I don't see a lot of other alternatives (other than Scarab, which I'd evaluate first).

Bug tracking / call handling

[JamesGreenhalgh]

I was put in charge of locating something good for bug handling / call handling for one of my ex employers networks. I started first of all by looking at the system we had (DDTS aka ClearDDTS, I think a product made by Rational) and looking at all the open source solutions.

Sadly I didn't find anything that was really up to the job. Lots of solutions that concentrated on software bugs, some better than others, but none that I thought were really good. Maybe that's a project for somebody? I know I don't have time unfortunately.

In case you're wondering, I then looked at commercial solutions, and found them to be severely lacking, or total mass overkill, all Windows based - so eventually we stuck with DDTS.

Ars Digita's Ticket module

[chowdmouse]

Have you considered using the Ticket module from ArsDigita Community System?

The developers where I work need a bug tracking system (right now it's a very crude process, stone tablets, lots of grunting, etc...you get the idea.) We've been considering using the Ticket [arsdigita.com] module from Ars Digita. [arsdigita.com] From the description it does all sorts of nifty things related to bug/enhancement/etc tracking. Anyone have any comments about this particular system?

Writing one for the Linux kernel

[goingware]

I have proposed writing one more or less from scratch at the Linux Quality Database Project [sunsite.dk].

It's just a proposal so far, I want to find a few developers to collaborate with before I start, but I'm also writing and posting articles there on the general topic of making Free Software of better quality and also testing the kernel in particular.

While this doesn't provide an answer to your question, some of what I plan would be useful to think about in selecting a bugbase.

The number one feature that I wished to have in bugbases at companies I've worked at in the past was for the user to have an ability to describe a configuration of a machine and then give it a name in the database.

Each user would have some number, one or many, preset machine configurations, particularly the hardware configurations in my case, and the components of these configurations would be drawn from a database describing every piece of hardware that could conceivably be placed in a Linux box.

Then when you go to report a bug, you log in (so your contact info and presets are available), select the config that has the bug, and describe it.

For the Linux kernel, you'd paste in or upload your .config file (this is created by the kernel configuration process).

Then kernel developers could do boolean searches, say "find me all the crashes involving TCP that had a WhizzyNet card installed but in which PPP is not configured in the kernel".

The other part of this is that it is meant to be easy to use for both those who test new kernels (to report bugs) and kernel developers (to research bug reports).

I got the idea to develop the database after subscribing to the linux-kernel mailing list [tux.org] to resolve a bug on my laptop [goingware.com] during the 2.4.0-test series kernels.

I was able to work with the list to resolve the bug and see that the patch stuck in the kernel sources, but I felt that many people who might otherwise like to contribute to testing new kernels might be put off by the process of dealing with the list - it's not sufficient simply to report a bug, sometimes patches don't "stick" and you've got to hang around until you're sure your bug stays fixed, but linux-kernel has one of the highest amounts of traffic of any internet mailing list.

Michael D. Crawford
GoingWare Inc