How To Track the Bug-Trackers? 174
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!)."
Stick with the post-its (Score:2, Insightful)
Needs to be managed by a person... (Score:4, Insightful)
There's probably a product where developers/bug-submitters can note the priority of their perceived bug, and can do this sort of thing for you. However, it doesn't solve the problem. Developers are going to pick the most interesting bugs to fix, not the most important (they're not always the same), and bug-submitters tend to think all their problems are life and death high priority. A manager is your best bet.
If you can't answer (Score:3, Insightful)
"How we doin' overall" then your not managing anything.
You set goals, you set milestones to get there, and you measure according to those goals.
When they don't meet, you explain why.
Simple... (Score:4, Insightful)
I fix bugs as they are reported. There are currently 0 outstanding bugs in the various software projects that I maintain.
Tasktop (Score:2, Insightful)
I use Tasktop. It is available as a standalone product or as an eclipse plug-in and will bring all the tasks from the multitude of bug trackers that I use for the various projects together so I can organize them as a todo list. So far it has worked great for me.
The second thing I like about tasktop is that it is an extension of the Mylyn project. Therefore it can limit what I see on my screen to items that are pertinent to my task, including interfacing with Firefox.
Re:Fix them (Score:5, Insightful)
That sounds great, until a week in you get to a bug that you can't fix because something else is blocking it. Now you start working on that second one for about a week before you realize that it, too, is being blocked by another bug. And so, and so on. Pretty soon, you're six months in, haven't accomplished anything, and are no closer to solving those dependencies. And without mapping them out as you go, you might not know which ones to go back and fix in which order. Not to mention, not all bugs are created equal. Some you can ignore for now, some cause the entire project to stop dead in its tracks.
No, the best solution is always to stop what you're doing, back up, and make sure everything is mapped out. Better to spend two weeks doing that and get all your ducks in a row rather than running off and making things worse than they already are.
Re:Simple... (Score:5, Insightful)
Must not be a widely-used application then. While this approach is laudable, it's hardly sustainable for any project of substance.
Re:WTF? (Score:3, Insightful)
Obviously you've never worked for a ginormous corporation with competing divisions and a history of mergers stretching back a century or more. Suffice to say, it's really not that uncommon for there to be different bug tracking systems. I work for a large telecom company, and while I only work on about four or five projects, there are at least five different bug trackers, project management tools, and various other bits of e-bureaucracy that I deal with every day.
Bug Tracking is even worse than Version Control (Score:4, Insightful)
Why can't anyone agree one what's "right to use"? It seems everyone and their dog has a bug tracker, and I've yet to see one that seemed to do its job "well". Is this something that has a secret really elegant solution that Linus can pull out of his ass in an afternoon and save us all?
I wouldn't expect it, since he uses /mailing lists/ of all things, to track things. I suppose it's sortof a decentralized model of bug tracking: everyone has to figure shit out for themselves.
If I don't see an easy way to note:
- A list of known issues
- Whether they're being worked on by anyone
- What I can do to help
- What the plans are for the future
I'm much less likely to like a project. Having to send an e-mail requesting these things on a case-by-case basis seems just plain stupid.
Perhaps some elegant solution is there somewhere, begging for someone to bring it to light. Just as git accepted that e-mailed patches would always be essential to any project which used version control, maybe something can be built which rests on top of a simple mailing list, and takes care of the history and classification which is the true purpose of issue tracking.
The best system of any sort is one which not everyone needs to actively use for anyone to get benefit from.
Re:Bug Tracking is even worse than Version Control (Score:3, Insightful)
Because its a multidimensional, subjective thing so, for any given person, there won't be one clearly superior product, and no two people will be guaranteed to have the same preferences.
What would be nice (and facilitate the kind of cross-tracker tracking that OP seems concerned about) would be some kind of least-common-denominator communication protocol and issue data format so that even if everyone isn't using the same tool, its possible to do basic centralized tracking of issues stored in different trackers.
Re:Simple... (Score:5, Insightful)
This doesn't scale.
Consider large-scale projects, something like the linux kernel, glibc, or X, where it is unreasonable to try and fix all bugs.
There are various reasons for this...some bugs can't be reliably reproduced so you add instrumentation to gather information when they do recur, others require months of uptime to reproduce, or special hardware/software that you don't have so it takes a long period of back-and-forth with someone that does have it.
Consider cases where you're too close to release to fix the bug "properly", so you paper over it temporarily but you want to leave a bug report open to remind you to fix it in the next release.
Re:Simple... (Score:3, Insightful)
Or maybe they have proper bug management, and assign the bugs based on priority and schedule impact. Why assign bugs to somebody if you know they won't be able to deal with them? They'll just end up with a huge list which won't be any help to their ability to focus on the critical issues. Yes, experienced engineers are better at managing their tasks, but it's still silly just assigning them willy-nilly as they will get lost in the system eventually.
We have at least weekly bug review boards with the product manager, engineering manager, lead engineer and QA lead. More frequently at other points in the dev cycle. The PM helps adjusts the priority of the issues, with the feedback from engineering who state how much effort they anticipate, and what if any schedule impact there will be, as well dependencies. The QA lead is responsible for the issues in the tracking system, ensuring it's scrubbed at certain points in the project, and raising the flag on any issues that need review or be deferred until the next dev cycle. It really isn't that hard.