Bug Tracking Database Systems? 7
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 (Score:1)
Anyways, good luck!
-mdek.net [mdek.net]
jitterbug and bugzilla (Score:2)
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 ... (Score:1)
Scarab (Score:2)
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 (Score:1)
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 (Score:1)
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 (Score:2)
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