How To Track the Bug-Trackers?

schneecrash writes "Submitting bug reports — and waiting for responses etc. — seems to be SOP for developers and users alike, these days. Every project has some sort of bug-tracker — bugzilla, trac, mailing list, etc. E.g., we currently track 200+ external bugs across ~40 OSS projects. Half the bugs depend on something else getting fixed, first. Every bug has its own email thread, etc. Management asks 'How we doin' overall?,' and suddenly everyone involved gets to work removing dried gum from the bottom of their shoe. What do Slashdotters use/recommend for centrally keeping track of all the bugs you track across all those different bugtrackers? In particular, managing communications and dependencies across bugs? So far, the best method I've managed to use is bunches of PostIt-notes stuck to the screen of an out-of-commission 32" TV (glossy, non-matte screen, of course!)."

This is more or less what I do

[Digital_Quartz]

We track bugs internally using Bugzilla. When we raise a bug against a project we depend on, we also raise a bug in our internal Bugzilla that links to the other bug, then we can use Bugzilla's depends-on and blocks to track the external bug.

The only downside is that someone needs to go and check periodically on the state of that external bug. It would be nice if Bugzilla let you mark a bug as "depends-on" a bug in someone else's Bugzilla.

Fix them

[RockMFR]

Just start fixing shit until you no longer have annoying dependencies. Bug-trackers are like interest on a loan - if you don't pay off the principal (the bugs themselves), you'll never get anywhere.

KnowledgeDNA

[doroshjt]

I've used KnowledgeDNA: http://www.kdna.com/ [kdna.com] works as a project management/task management solution, keeps status of tasks and allows tasks to be dependent on other tasks.

The 2.5 I've used

[Scareduck]

• Bugzilla: still the best, as far as I'm concerned, because it quantifies communication (you know who bug changes will go to), has good search features, and is free. The big downsides are mostly from a management perspective: no time tracking, too chatty (i.e. if you only care about state transition on bug completion, you get to listen on all the other crap, too), and no integration with management tracking tools. The nits I have from a worker-bee perspective are that Bugzilla can't eliminate a project once it's been created (hiding would really be a better word); this has been a feature request that's been ignored for years now. This makes deciding where to put a bug much more difficult than it otherwise needs to be.
• Fogbugz: Mostly fixes the managerial problems with Bugzilla but at the expense of horrific communication problems elsewhere.
  • It wants to use e-mail as its primary means of communication, yet an absence of integration with LDAP (or any means of establishing a list of authorized users) means it doesn't support auto-fill-in for e-mail fields as it does for, say, bug assignment.
  • It doesn't automatically let the author of the bug -- or anyone else! -- know if something has changed on the bug; you have to explicitly request this, and there is no preference to automatically change this for auto-subscribe to bugs you write or are assigned to.
  • Similarly, there is no way to know who is subscribed to a bug. This is simply inexcusable for a bug tracking system; the whole point is communication.
  • The filter interface doesn't include all options. One of the most irritating misfeatures of this package is the fact that many crucial search options are available as text-only operators, and do not appear on the user interface.
  • E-mail always appears to come from the Fogbugz administrative user no matter who originated it. The package appears to be made by people who had no desire to communicate with each other...
  • ... as evidenced by their built-in preference for TOFU quoting [wikipedia.org] .
  • Formatting is a nightmare. Bugzilla, at least, guarantees fixed-width fonts, so tables and code examples are readable; Fogbugz insists on using variable-width fonts, which wreaks havoc with code. And there's no way to use HTML, either (though this is an equally valid criticism of Bugzilla).

  That's just the start.

• trac: Mercifully, I didn't have to use this much, but the learning curve appeared to be rather steep, and it was a completely alien experience from Bugzilla.

Re:This is more or less what I do

[h2g2bob]

launchpad.net automatically watches some external bug tracker, so it must be possible.

Re:This is more or less what I do

[CodeDragon]

launchpad.net automatically watches some external bug tracker, so it must be possible.

Launchpad can also sync comments bi-directionally with some bug trackers (Trac and Bugzillas that install a Launchpad API plugin. Bugzilla 3.4 instances will also be supported).

Disclosure: I'm a Launchpad developer.

Re:The 2.5 I've used

[cca93014]

Bugzilla has "good search features"? Whenever I try and search a bugzilla database I seem to either get 0 hits or about 8 billion. Really. It's like a magic trick or something...

JIRA is the best bug tracker out there IMHO...

Extension addressnig

[belg4mit]

Why not use plus addressing to map any outside correspondence about
the status of your external bug to one in your internal tracker?
This presumes the outside project has a sane system, and may require
a separate account for every bug though. Many similar possibilites
exist e.g; maintain a table for your mail daemon to the mapping
rather than using accounts to do so.

If you've got issues, try JIRA!

[thomas.mitchell]

I use and develop plugins for Atlassian's bug tracker JIRA, which I find to be a good package. Out of the box it has configurable issue types, workflows, status's, priorities, issue fields, etc. It's architecture also makes it easy to develop extensions for when you need some unusual functionality. At work, we use it to track bugs, keep tabs on library loans, log time, record communication with clients, report on workloads, etc, etc. It's pretty central to our business in other words. If you're after a commercial solution, I seriously reccommend you take a look at it. As a bonus, it was built to be easily integrated with Atlassian's wiki Confluence, which has the same strengths.