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.
Seriously, I've found them to be the best method of issue tracking.
Prediction: The real iPhone killer is going to be sex robots from Japan. Think about it.
Within a project all related tickets should be able to update you when one of the related tickets changes (RSS feed, email, etc).
Across multiple bugtrack systems and projects...trickier.
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.
bring the flames...
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.
As a changelog, I love it. As a bug tracker, I have to say that it lacks. JIRA is better. .02
The programmer in the back of my mind will lynch me for saying this, but this is the only way I see out of the gordian knot:
Define them all as issues in one giant project and try to map out all the dependencies.
That way, you know what bugs are awaiting what (forwards) and which bug you can work on when a certain bug was fixed (forwards).
Ths only problem is assigning the management of the chart (or parts of it).
Probably the person in charge of the team that reported the bug.
Should a bug fail to make any progress, the offending external package might be swapped out for something else.
"I was in love with a beautiful blonde once, dear. She drove me to drink. It's the one thing I am indebted to her for."
"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
Best bug-tracking bug tracker out there.
(pimping project)
Get RSS feeds of everything, drop me a line, and we could do something like http://www.wallcloud.net/
aggregating the data and then finding clusters.
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.
Why the heck is your company allowing every project manager to roll their own bug-tracking system in the first place? Everyone probably has their own fscked revision control and change management packages too. Get a robust tracking system (or even a CRM system) that allows tracking of issues, bugs and changes for multiple projects all in one database. Even a small business (10-20 employees) can benefit from this kind of consolidation in the long run.
If you don't have the resources or inclination to do a consolidated environment, at least get all the projects on the same platform, so that everyone is using the same software within their environment. It saves training costs, customer confusion, and will save time when the time comes to actually do a consolidated environment.
We are the 198 proof..
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
Try http://www.ohloh.net/
Mantis - open source web bug tracker
FogBugz - already described previously
Sharepoint - Part of WSS and MOSS
The place I'm at now uses Team Foundation Studio. It works well, though might be more then a smaller shop needs. The last place I was at used trac, but AFAIK, it doesn't have a very robust method of accounting for bug dependencies.
Hikery.net - The best hiking site ever. Made by yours truly.
Debian's bug tracking system (see bugs.debian.org) is probably a bit difficult to learn all of the useful features it has, but I find it's one of the best. It can:
* Operate entirely by email, without needing logins and the like.
* Anyone can subscribe to any bug they find interesting.
* Users can assign any "usertags" they like to a bug, to keep track of cross-cutting concerns, or to get summaries of an arbitrary collection of bugs on one page.
* Keep track of bugs forwarded upstream and automatically update the bug status at home (to fixed-upstream) when the upstream bug is fixed.
* Keep track of which bugs block which other bugs.
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.
Nao I wish to go writz as Bug-Trackin softwarez that will not let you submitz bugz abt itself. Will give "Error 403: Forbidden; Douchebaggery" and link to ze nonexistant bug article for the bug of Douchebaggery.
Bugzilla 3.4 will have rudimentary support for saying that a bug is related to a bug in another bug-tracker. Currently the development version allows you to input Bugzilla and Launchpad bugs, and we'll probably allow Trac and Jira in some future version, too.
Future versions will also automatically update the other bug tracker, if possible, to let them know that you've set a relationship to their bug.
The relevant bug for tracking development on this feature is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=bz-seealso
-Max
Everything Solved, High-Quality Bugzilla, Perl, and Linux Services
Tps reports
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
Without a doubt is has to be JIRA.
I was asked recently to implement the transition from Bugzilla to JIRA. The engineers/support guys that used Bugzilla loved it. Before the switch-over there was a lot of resistance... however, once they saw the power of JIRA they never wanted to go back.
We have over 100 products in JIRA split into 10 categories. The company has offices in most continents and all of them access JIRA without a problem.
Most bug tracking software can do dependent links or related bugs. But when it comes down to it you have to use your feet and go walk over to people and actually talk to them if your stuff needs fixing. By going around and chatting with people you're dependent on you'll always have a sense for what's going on and when management comes to ask you can stop staring at your gum-filled shoes and give 'em a straight answer. :)
Neil
The easiest thing to do is write software without bugs. Duh.
My Company like many others I am sure, thinks it's special and no one else has issues like it does... So they have their own homegrown bug tracking software... which some guy gets the great idea to replace with another home grown solution every 4-5 years, and surely gets promoted...
In setting up our local instance of this stuff it seems like management doesn't understand the basics of tracking issues... And they sure as heck won't take our words for it...
So... does anyone know of any books on the subject of how to generically track issues... I would love to buy a copy and "drop" it on my Managers desk...
Going to get shot for this suggestion but MS Team Foundation Server.
It's pretty unbelievable, very powerful and extremely customizable!!!
Does way more than tracking bugs, as i tell my QA guy daily "EVERYTHING IS NOT A BUG!!!!"
Somethings are requirements, tasks, etc...
why don't you hve a scrum board, with a color for each bugtracking system that you have. you could eventualy consolidate the bug trackers at some point.
By filing bugs in it, of course.
http://www.donarmstrong.com
We use Eventum - developed by mySQL team, so well used on a big project.
We have written our own custom reports that allows us to easily assign a load of bugs in bulk to someone else -- thats a great way of keeping your buglist empty :-)
http://en.wikipedia.org/wiki/Internet_Relay_Chat
The only good solution is good communication.
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.
Debian's bug tracker deals with this well. It understands many different types of bug trackers - IIRC, among them launchpad, bugzilla, trac. If a bug is opened with Debian, it can be forwarded upstream, and when it's resolved, Debian's bug tracker will mark it as 'resolved upstream', and it can be closed when a package with the fix is uploaded.
Our company started out on Bugzilla. We actually had some informal training on that. The nice thing is it sends out e-mails, so I can actually look at my inbox and know that I have issues that need fixing. Then they switched to Netoffice. They never gave any training on Net Office, but at least NetOffice was good enough to send out e-mails as well. I didn't even know where Netoffice was located or what my password was, although they obviously set me up an account. So whenever I fixed a bug, I would just e-mail back the person telling them to close it because I didn't know how. Then, they switched to Jira. We no longer get e-mails when an issue is raised, although I am SURE that Jira has such a feature. Again, there has been no training, indication of where Jira can be found, or what my username or password is, although I again know that I have an account, because people occasionally send me an excel spreadsheet with all of my past due issues in Jira. Of course, that is another whole argument. When you report a bug, you don't get to set the due date. The receiver of the bug sets the due date. I have not yet received the bug, therefore it has no due date. On top of that, I still have bugs in bugzilla and netoffice that haven't gone away yet.
We have a stupidly high ratio of Project Managers to developers where I work. The assumption is that since they have all kinds of time to go to lunch, gab with each other, go home early, go socialize with the customers and eat breakfast and lunch on the company, that we in the development area (actually I am in operations, but my boss tells people I am in development) are similarly bored and just aching to go spend time each day perusing some website to see if there is more work to do.
If you are not allowed to question your government then the government has answered your question.
Well, I can do a little better than that (if not much). I keep a folder full of bookmarks to the URLs of reports I've filed in external trackers.
And of course, most trackers send you email when things change.
This has worked for me, but I only track a half dozen bugs at a time, a far cry from the 200 mentioned in TFS.
You need a bug tracking tool with traceability. Traceability allows you to create special links or "traces" between items like bugs, requirements, and use cases if your team uses those. Try TopTeam, with some help with the dev team Im sure you could get some syncronizers for your other tools too.
Whatever you choose--please do not let it be Trac, which is a piece of garbage. Go ahead and try to install and maintain it: I dare you. What a mishmash of bizarre pieces of other crap bolted together.
I went to a really good talk about how to use pre and post commit hooks in Trac to make other (external) events happen. Provided there's not too large a universe of bug trackets in common use out there, you could push comments into other trackers or pull related threads back into yours.
i.e. Closing the ticket when "papering over" a bug creates a new ticket to have a proper fix tagged as a requested enhancment.
i.e. If the other trackest also have a Wiki, link to the objects in your own tickets. For example, I was recently trying to solve a libiconv linker bug that only happens on Solaris when GNU and Sun headers are installed. I found my answer in a completely different application that happened to be trying to use the same library in similar circumstances.
Sort of like how HTTP moved us into a web centric model away from hierarchical approachs like Gopher.
Xix.
"Everything is adjustable, provided you have the right tools"
oh wait, i thought this was the religion channel.
Probably the biggest irritation for me wasn't figuring out which bugs depend on which -- I'd always have some I know I have to work on. Bugs blocking anything critical get bumped up in priority, so I, as a programmer, don't have to think too hard.
So, sure, a dependency system would be great. Trac-style linking is essential, anyway, for humans to refer to one commit or another.
But, what's been interesting me lately are things like Ditz, which stores issues as yaml files which can be easily managed through version control. Combine with a distributed VCS like Git, and you have a system where the exact change which resolves the issue can also close it in the tracker. Thus, it's easy to find exactly which bugs are outstanding for any given build.
Don't thank God, thank a doctor!
Ok, I definitely have my quips about MS, but seriously people, Team Foundation Server is absolutely amazing. The bug tracking, management, and reporting features of it, team explorer, and team plain are second to none from everything else our team and has tried and used. Track the trackers? Sure, run a report any number of queried reports on closure rate, new bug rates, and such, and have it show you a pretty graph of it all with great detail information. Add to this that it includes a fantastic version control system that makes make everything else look archaic, and I'm sorry, but I really have to hand it to MS for this one.
I release this solution is really only applicable for for profit operations, generally building .net applications, but it works great.
zAgile gives you a composite view of all your bug trackers (and other tools and applications). www.zagile.com
I use Redmine exclusively for my projects.
Works as a complete project management tool. It manages the source control, has a wiki, a forum, something that looks like a cross between a coffee maker and nose-hair clippers, oh, and a bug tracker.
The bug-tracker allows you to make bugs dependent upon bugs from other projects.
At the great risk of shooting myself in the foot, I submit my instance of Redmine for your perusal. Please don't abuse my site, it's just a little pokey VPS.
http://www.fsdev.net/ --- Redmine be there
Consider yourself spoken to.
We're currently working on trying to develop such an opensource tool that would allow bugs synchronisation between different bugtrackers. There's not much yet as the project just started a couple weeks ago, but I hope we can achieve something to solve that issue. Our first tasks have been to look at bts-link and also investigate the use of ontologies, RDF and semantic annotations or Linked Data concepts. More details here : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Helios_wp3/Web/
One tracker that hasn't been mentioned that I'm enjoying using is Roundup. It's written in Python, uses the TAL template language, and is really easy to customise if the base install doesn't suit your needs. I really recommend that you check it out.
Within the development site where I work we're using a self developed meta bug tracking system which can merge data via API. This approach has the disadvantage that the bug tracking system can be slower but it has the advantage that additional information that is used for planning purpose can be stored within "global fields" which are stored within a local database.
I wonder if Google Tasks could be used a lightweight system.. this is available with gmail, as an addon from Google Labs. Just a way to change an email to a Task and then to mark it completed.
So it's not really a solution for a group, just perhaps for a single individual.. lol
I'd highly recommend the Rational Suite from IBM. Their ClearQuest product is great. I use it every day in my company. It has...
- Severity tracking: categorize or re-categorize your bug according to severity
- Source control integration: link your bug directly to one or more source files with a direct link to ClearCase (the sister Rational application...highly recommended)
- Authentication plugins: standalone database (DB2 UDB) or LDAP/AD
- Authorization: fine grained, with approvers list and list of team assignees
- Project based: each bug goes to a project, which is can be managed separately by what I've mentioned above
- Reporting: crystal reports, SQL, internal query language, Perl
We maintain dashboards of the projects maintain in our ClearQuest system, so we essentially just run a report to get the stuff out of CQ and quickly have access to a 10,000 ft overview of the status of a project.
df -h
we currently track 200+ external bugs across ~40 OSS projects
If the number of bugs tracked becomes that large, it might be time to pro-actively talk to management and find some budget to get those things fixed and the fixes contributed.
That would reduce the number of bugs and make the whole world a better place.
Busy helping non technical users of OpenOffice.org - http://plan-b-for-openoffice.org/
We use Mantis, to track ~10k bugs now over a few software projects (can sort by projects). You can relate bugs to each other: parent/child or related etc. This helps knowing what ones need to be fixed 1st if that's your main issue. I'm sure all bug trackers would have similar features.
I've been using Roundup Tracker http://roundup.sourceforge.net/ at work for a while, and it's been a great experience. Stable, fast, and very easy to mod/customize to your own needs or preferences (it's written in python).
An live example of the web interface of a roundup tracker can be seen online at http://bugs.python.org/
At my first job, we used some Rational tool to manage our bugs... I forget the name of it, but it got the job done. Where I work now, we use Bugzilla. I think Bugzilla has some room for improvement, but it gets the job done.
My real issue with how my company uses Bugzilla is that if I don't work with it all day long; I really don't understand the conventions in place needed for the proper workflow. I don't think this is a technological problem, as any collaboration application used by a lot of people will have a learning curve..
No, I will not work for your startup
I'm a big fan of rt3 ( http://bestpractical.com/rt ).
Pros:
- Free and open source
- Web, email, and command line interface
- Flexible (I've used for bug tracking, support departments, task and project management, documentation, mailing lists, and more)
- Scalable (I've seen it go beyond 100,000 tickets on an average server with no performance hit)
- Excellent community (mailing lists, wiki, book, contrib section on the site)
Cons:
- Written in Perl, so its a bit tricky to configure and customize
Give it a try.
Leonid Mamtchenkov