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!)."
A Jira of Jiras.
I have a nice wire-frame basket designated for bug reports, electric bills, fast food wrappers, and soda cans.
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.
Windows people use the recycling bin instead of the trash can.
Engineering is the art of compromise.
Bug tracking software is great, and we implement it at our workplace (large company, so there are several solutions depending on what sort of project it is). However, it's important that the overall management gets done by a person. Put a person in charge of all bug fixes, have them start a Microsoft Project (or whatever the OSS solution is) file that tracks everything, assigns each bug to a person, and puts them in order of priority. Bug reports go in your bugzilla, this person gets notified, they map out the priority of the bug, who's skillset best fits it, when and how fast it needs to get done, etc.
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.
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.
I've used KnowledgeDNA: http://www.kdna.com/ works as a project management/task management solution, keeps status of tasks and allows tasks to be dependent on other tasks.
"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.
The Kruger Dunning explains most post on
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.
I fix bugs as they are reported. There are currently 0 outstanding bugs in the various software projects that I maintain.
That's just the start.
Dog is my co-pilot.
I almost fell out of my chair. I literally have a 32" TV that is half covered in post it notes containing bug reports and other issues. Personally I find the TV method perfectly sufficient. I should also point out that the screen faces the door to my office, so it doubles as a mirror, thus I can see who's sneaking up on me. Multi-purpose tools are always the best.
ed duval the very last person
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.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
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.
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.
God invented whiskey so the Irish would not rule the world.
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.
-- 'The' Lord and Master Bitman On High, Master Of All
"Once bugzilla implements the features in the next version and/or fixes bug #233412 and #455354, and Trac patches the rss feed problem, and...well, I just don't know how I'm going to keep track of all these bugfixes so I can get my bugfix tracking program working properly!"
Seriously, I've found them to be the best method of issue tracking.
Your .NET program just crashed with a stack trace of a size that is only rivaled by Java. Please visit your postal clerk in a few days to pick up the extremely large package I sent (at considerable personal cost) containing 12,345 post-it notes.
There's no place like
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.
Were that I say, pancakes?
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.
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.
a good manager will check your plans, then quietly observe as the experts 'do their thing' and occasionally inquires to the status (AKA can I help)?
How I wish ... in the real world, there are 4 levels of bug tracking that my boss uses.
Level 1 - An email entitled "can you fix this ?".
Level 2 - An email entitled "why isn't it fixed yet ?" (which arrives 15 minutes after the Level 1).
Level 3 - An email entitled "URGENT - fix it now !!!" (complete with red exclamation mark, which arrives about an hour after the Level 3).
Level 4 - An email entitled "It's taking too long, leave it, we'll live with it" (the closest I come to closing something out - usually about 2 days after the Level 3).