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!)."
Re:Internal (Score:3, Interesting)
we currently track 200+ external bugs across ~40 OSS projects. Half the bugs depend on something else getting fixed, first.
lymond01 writes
Across multiple bugtrack systems and projects...trickier.
I'm working on a lightweight system designed exactly for this problem. And when I can get enough internal interest in getting the project through the opensource process, it may see the light of day sometime in the next few months. Until then, use bugzillas dependency fields, launchpad or post it notes. Sorry.
Re:Staples Calendars! (Score:4, Interesting)
What I think I hear you saying, translated, is "you keep manual mini-notes of 30 words or less on discrete topics."
I try to use PostIts for really ultra-short things that I know will go away in less than a couple hours. But when suddenly some topic cascades, I gather the 7-odd Postit notes and then follow the issue on a re-purposed Staples Desk Calendar. Those little squares are the same size, and lined! Then you can track some 60 episodes per page with 3-stage Progress per episode. Then when there's only about 3-4 issues left I clean up the battle scarred mess into one 8x11 sheet of paper drawn into quadrants, whose issues are typically the ones "parked". You can scan those and just look at them once a month to see if someone woke up & fixed something.
Re:Simple... (Score:3, Interesting)
The most widely used application is used by thousands of people in over 50 countries. I consider it a "project of substance." :)
jello dancers (Score:5, Interesting)
Judging by what you didn't discuss, you don't seem to distinguish fixing surface manifestations from root causes. I find that when I focus on addressing root cause, I don't run into this regression. Code is correct when it performs as specified in the design and API documents. If that means the entire application bombs out because something on the other side is broken, that's a separate consideration.
Put in the correct code (as if the other side is also correct) and then mark the bug as fixed, pending final validation when the other side is also fixed.
If addition of correct code makes the surface manifestation unbearable (application constantly bombs), then you can restore the broken code as a temporary work-around, to be removed as soon as the bug on the other side of the interface is properly addressed.
If one side of the API knows which cases are failing on the other side, you might be able to detect the suspect case and write a record to the log file "overlapping FOO handled by dubious heuristic BAR". Then if the work-around code causes a downstream cascade of weirdness, people don't get too quick to decide that another 100 bugs need to be reported.
I've also found that conservative design and coding conventions mitigates these interdependency cascades.
It can be a good idea wading into an unstable code base to pare down to a completely stable build. This is a build where you compile out functionality until what remains is believed to be rock solid. If your rock solid build is hugely divergent from your production build, then you likely have a serious cultural or management problem.
It's almost always faster in the long run to merge solid code back into the rock solid build than jello diving on an unstable production build.
On a big project, it's great to have a couple of world class jello divers to actually get the product out the door.
It should never be half of your release team. An ecology of jello dancers tends to support only one big fish, as the Microsoft story illustrates. When half of your release team is 100 FTEs, it's amazing what you can pass off the buying public long enough to rinse and repeat.
I can also say as an architect that I'm wounded to the core if my code base degenerates into a cascade of jello dancing. More than once I've seen the exact moment where a solid code base takes a bad turn. One time I took a several weeks off due to a death in the family at a critical design juncture. Everyone worked really hard to fill in the gap, and some new features were completed in record time by bastardizing one facility to do what it hadn't been intended to do. The project lived to see another day. The software was never as solid again. It's brutally hard to back these things out.
I've also sat down to discuss implementation strategies with other developers only to discover the person was navigating around the core difficulty in the belief that he ended up with would handle 99% of the cases required by the next shipment point. The person might look at this as the difference between one day to whip it out (cue infantile jokes), instead of three days to nail the specification, at a point in the deliver schedule when days (and nights) are precious resources.
It's a false calculus once you consider the downstream investment in validating the code, shipping the code and obtaining marketplace confidence, bug reporting cycles, and the persistent niggling fear that every subtle bug "could be one of five or ten different corner cases we shaved off in the last iteration".
No large project is ever shipped without cutting corners, but you have to choose your battles carefully. If you end up with a cascade of interdependent bugs, someone along the way made some unwise choices.
By the time you are proposing to build a meta-bug tracker because these interaction chains exceed what can be mentally managed, it sounds like a invitation to a bring in an MBA student to write a case study of a business whose business model had degenerated into managing their own dysfunction. I would think long and hard about this before I mastered my queasy feeling.