Slashdot Mirror
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!)."
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.
God invented whiskey so the Irish would not rule the world.
Must not be a widely-used application then. While this approach is laudable, it's hardly sustainable for any project of substance.
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.