Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How To Track the Bug-Trackers?

timothy posted more than 5 years ago | from the and-what-if-they-have-a-bug dept.

Bug 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!)."

Sorry! There are no comments related to the filter you selected.

Recursive Bugtracking (3, Funny)

CompMD (522020) | more than 5 years ago | (#26644819)

A Jira of Jiras.

This is more or less what I do (4, Informative)

Digital_Quartz (75366) | more than 5 years ago | (#26644927)

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.

Re:This is more or less what I do (4, Informative)

h2g2bob (948006) | more than 5 years ago | (#26645439)

launchpad.net automatically watches some external bug tracker, so it must be possible.

Re:This is more or less what I do (5, Informative)

CodeDragon (987401) | more than 5 years ago | (#26646033)

launchpad.net automatically watches some external bug tracker, so it must be possible.

Launchpad can also sync comments bi-directionally with some bug trackers (Trac and Bugzillas that install a Launchpad API plugin. Bugzilla 3.4 instances will also be supported).

Disclosure: I'm a Launchpad developer.

Re:This is more or less what I do (5, Funny)

Bozzio (183974) | more than 5 years ago | (#26646241)

Launchpad can also crash anything that flies (surviving the crash, of course).

(Mods, if you're too young to remember this, then DON'T MOD)

Re:This is more or less what I do (1)

madhurms (736552) | more than 5 years ago | (#26646805)

(Mods, if you're too young to remember this, then DON'T MOD)

Allright, you convinced me!!

Re:This is more or less what I do (0)

Anonymous Coward | more than 5 years ago | (#26646975)

Now how can I convince you to spellcheck?

Re:This is more or less what I do (2, Funny)

cinderblock (1102693) | more than 5 years ago | (#26646949)

Quick, file a feature request ticket.

Re:Recursive Bugtracking (0)

pak9rabid (1011935) | more than 5 years ago | (#26645155)

One JIRA to rule them all.

Re:Recursive Bugtracking (4, Funny)

CompMD (522020) | more than 5 years ago | (#26645665)

and if you use LDAP instead of Crowd for user management, then in the darkness it can in fact bind them.

Basket (5, Funny)

Tubal-Cain (1289912) | more than 5 years ago | (#26644843)

I have a nice wire-frame basket designated for bug reports, electric bills, fast food wrappers, and soda cans.

Mac user? (2, Funny)

EmbeddedJanitor (597831) | more than 5 years ago | (#26644961)

Windows people use the recycling bin instead of the trash can.

Re:Mac user? (2, Funny)

redJag (662818) | more than 5 years ago | (#26645031)

well, it is a wire-frame basket icon in OS X.. so maybe!

Re:Mac user? (2, Funny)

Anonymous Coward | more than 5 years ago | (#26645061)

I first thought "Who cares?" but after seeing your nick, I understand why it is so important difference to you.

Re:Mac user? (1)

Tubal-Cain (1289912) | more than 5 years ago | (#26645221)

No, not a Mac user. I haven't figured out how to send food packaging to any OS's equivalent of /dev/null

Re:Basket (1)

Cyberax (705495) | more than 5 years ago | (#26646785)

You mean "a low-profile circular filing cabinet"?

Stick with the post-its (1, Insightful)

Gat0r30y (957941) | more than 5 years ago | (#26644855)

Seriously, I've found them to be the best method of issue tracking.

Re:Staples Calendars! (3, Interesting)

TaoPhoenix (980487) | more than 5 years ago | (#26645507)

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:Stick with the post-its (4, Funny)

darkpixel2k (623900) | more than 5 years ago | (#26646273)

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.

Re:Stick with the post-its (0)

Anonymous Coward | more than 5 years ago | (#26646405)

yeah, use the glass on that dell 1100
you pushed off to the side 3 years ago.
jr

Internal (1)

lymond01 (314120) | more than 5 years ago | (#26644897)

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.

Re:Internal (2, Interesting)

An dochasac (591582) | more than 5 years ago | (#26645185)

schneecrash writes

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:Internal (4, Funny)

lymond01 (314120) | more than 5 years ago | (#26646087)

"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!"

SharePoint list (0)

Anonymous Coward | more than 5 years ago | (#26644933)

bring the flames...

Needs to be managed by a person... (3, Insightful)

The Dancing Panda (1321121) | more than 5 years ago | (#26644963)

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.

Re:Needs to be managed by a person... (0)

Anonymous Coward | more than 5 years ago | (#26646133)

Yeah, also known as a QA lead.

Re:Needs to be managed by a person... (1)

techno-vampire (666512) | more than 5 years ago | (#26646753)

bug-submitters tend to think all their problems are life and death high priority.

Not always. I've submitted a number of bugs to different projects over the years, and I've never yet marked one as high priority. In fact, I made a bug report yesterday that I marked as Low, because it was recommended by SeLinux that I file a report, but it didn't have any obvious symptoms.

Fix them (3, Informative)

RockMFR (1022315) | more than 5 years ago | (#26644987)

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.

Re:Fix them (1)

Matheus (586080) | more than 5 years ago | (#26645065)

Just don't write bugs in the first place and write all modules that you need for your own project.

"I didn't reinvent the wheel.. I made it better!"

Re:Fix them (4, Insightful)

corbettw (214229) | more than 5 years ago | (#26645539)

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:Fix them (1)

Otto (17870) | more than 5 years ago | (#26647655)

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.

What kind of freakin' "bug" takes a bloody week to work on?

PROTIP: Start your task by breaking big bugs into smaller bugs. Seriously, use that bug tracker to full advantage. As you figure out the issue, make new bug reports for each of the (small) pieces of the problem. Then put in the original bug that it has been subdivided into bug A, B, C, etc. Then start working on each one of those, closing them as you go.

Advantages to this:
a) In a multi-developer environment, one of the other devs might come along and fix one of the pieces for you, closing it in the process. Less work for you is a good thing.
b) If your bugtracker is worth a damn, then you'll be able to see the status of the sub-bugs on the original report, and when they're all closed, you can write "fixed" and get on with your life.
c) Dependencies won't stop you dead in the water, you'll be able to keep tracking what you're doing and when.
d) Management number inflation. We fixed X bugs this week!

Bug trackers work great for small problems. And all large problems are just a series of small problems. :)

KnowledgeDNA (3, Informative)

doroshjt (1044472) | more than 5 years ago | (#26644995)

I've used KnowledgeDNA: http://www.kdna.com/ [kdna.com] works as a project management/task management solution, keeps status of tasks and allows tasks to be dependent on other tasks.

Trac (0)

Anonymous Coward | more than 5 years ago | (#26645001)

As a changelog, I love it. As a bug tracker, I have to say that it lacks. JIRA is better. .02

One giant Gantt Chart (1)

kitgerrits (1034262) | more than 5 years ago | (#26645019)

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.

Re:One giant Gantt Chart (1)

cyphercell (843398) | more than 5 years ago | (#26645285)

The programmer in the back of your mind should. Why use a gantt chart which models time when you can use a DAG which models only the dependencies? Unless you are using the time aspect as a deadline for replacing the offending module.

Re:One giant Gantt Chart (1)

DragonWriter (970822) | more than 5 years ago | (#26645379)

The programmer in the back of your mind should. Why use a gantt chart which models time when you can use a DAG which models only the dependencies?

Well, the original question was how to respond to management "how are we doing?" questions, and management likes to have expectation of time to certain goals. Of course, unless there at time commitments associated with all the bugs (many of which are external) involved, the time piece of your gantt chart is going to be a wag anyway, but if you have the kind of management that care more about precision and presentation than accuracy, then I suppose it might still be useful.

Re:One giant Gantt Chart (1)

cyphercell (843398) | more than 5 years ago | (#26646443)

Ahh, a little WAG, precision and presentation works much better than screaming "P does not equal NP".

I am not a professional programmer, I just think DAGs would work a lot better in this case where everything is external and deadlines cannot reasonably be made while relying on external resources.

Re:One giant Gantt Chart (1)

kitgerrits (1034262) | more than 5 years ago | (#26645499)

I have to admit that I am not a professional programmer and that I have never heard of a DAG model.
I'm more of a Prince2 (project-oriented) person.

Projects tent to be defined by the fact that they have a deadline.
What most managers want to know is: will I still amke my deadline?
If something threatens that deadline, they want to be the first to know, so they can work on a (re)solution (apply pressure, different program, hire (bribe) the FOSS programmer, hire an expert, re-allocate resources, extend deadline, anything).

From what I have experienced, 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)?
As soon as the project sets off, the manager is only really needed to provide resources and report to the management layer.

If you can't answer (2, Insightful)

geekoid (135745) | more than 5 years ago | (#26645021)

"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.

I use bugzilla-zilla (0)

Anonymous Coward | more than 5 years ago | (#26645041)

Best bug-tracking bug tracker out there.

RSS, aggregate, cluster (0)

Anonymous Coward | more than 5 years ago | (#26645173)

(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.

Simple... (3, Insightful)

kmsigel (306018) | more than 5 years ago | (#26645235)

I fix bugs as they are reported. There are currently 0 outstanding bugs in the various software projects that I maintain.

Re:Simple... (0)

Anonymous Coward | more than 5 years ago | (#26645529)

Wait, you mean you can choose to fix stuff instead of defering everything so it gets lost in a mountain of tickets and nothing non-critical ever gets done?? I've gotta tell my PM about this!

Re:Simple... (5, Insightful)

pongo000 (97357) | more than 5 years ago | (#26645541)

Must not be a widely-used application then. While this approach is laudable, it's hardly sustainable for any project of substance.

Re:Simple... (2, Interesting)

kmsigel (306018) | more than 5 years ago | (#26645751)

The most widely used application is used by thousands of people in over 50 countries. I consider it a "project of substance." :)

Re:Simple... (1)

stemcel (1074448) | more than 5 years ago | (#26646289)

Pictures or it didn't happen ;)

But seriously though, I'm curious.

Re:Simple... (2, Insightful)

Malc (1751) | more than 5 years ago | (#26646857)

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.

Re:Simple... (1)

corbettw (214229) | more than 5 years ago | (#26645559)

I could be wrong, but I think the person who asked this question is dealing with a situation where bugs have built up over time, and now he has to go in and clean them all out. Obviously dealing with bugs as they are reported is ideal, but not everyone finds themselves in an ideal situation at all times.

Re:Simple... (1)

sorak (246725) | more than 5 years ago | (#26645903)

Bug #1.
Donna keeps bitching about my software. time to "fix her".

Bug #2.
Never mind. Eric is a quick learner. bug fixed.

Re:Simple... (4, Insightful)

Chirs (87576) | more than 5 years ago | (#26646147)

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... (4, Funny)

Onymous Coward (97719) | more than 5 years ago | (#26646307)

a.k.a. "Look at my dick, it's enormous."

Re:Simple... (0)

Anonymous Coward | more than 5 years ago | (#26646863)

Apparently your software does not have any users either.

Re:Simple... (1)

SLi (132609) | more than 5 years ago | (#26647709)

Fix them or close them as "I don't think this is a bug"?

Do you have any clueless users?

What I want to know is... (-1, Offtopic)

Nerdposeur (910128) | more than 5 years ago | (#26645251)

...how do you track bugs in your bug-tracking software?

Re:What I want to know is... (1)

Stauken (1392809) | more than 5 years ago | (#26645587)

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.

Re:What I want to know is... (1)

dondelelcaro (81997) | more than 5 years ago | (#26647183)

By filing bugs [debian.org] in it [debian.org] , of course.

The 2.5 I've used (4, Informative)

Scareduck (177470) | more than 5 years ago | (#26645287)

  • Bugzilla: still the best, as far as I'm concerned, because it quantifies communication (you know who bug changes will go to), has good search features, and is free. The big downsides are mostly from a management perspective: no time tracking, too chatty (i.e. if you only care about state transition on bug completion, you get to listen on all the other crap, too), and no integration with management tracking tools. The nits I have from a worker-bee perspective are that Bugzilla can't eliminate a project once it's been created (hiding would really be a better word); this has been a feature request that's been ignored for years now. This makes deciding where to put a bug much more difficult than it otherwise needs to be.
  • Fogbugz: Mostly fixes the managerial problems with Bugzilla but at the expense of horrific communication problems elsewhere.
    • It wants to use e-mail as its primary means of communication, yet an absence of integration with LDAP (or any means of establishing a list of authorized users) means it doesn't support auto-fill-in for e-mail fields as it does for, say, bug assignment.
    • It doesn't automatically let the author of the bug -- or anyone else! -- know if something has changed on the bug; you have to explicitly request this, and there is no preference to automatically change this for auto-subscribe to bugs you write or are assigned to.
    • Similarly, there is no way to know who is subscribed to a bug. This is simply inexcusable for a bug tracking system; the whole point is communication.
    • The filter interface doesn't include all options. One of the most irritating misfeatures of this package is the fact that many crucial search options are available as text-only operators, and do not appear on the user interface.
    • E-mail always appears to come from the Fogbugz administrative user no matter who originated it. The package appears to be made by people who had no desire to communicate with each other...
    • ... as evidenced by their built-in preference for TOFU quoting [wikipedia.org] .
    • Formatting is a nightmare. Bugzilla, at least, guarantees fixed-width fonts, so tables and code examples are readable; Fogbugz insists on using variable-width fonts, which wreaks havoc with code. And there's no way to use HTML, either (though this is an equally valid criticism of Bugzilla).

    That's just the start.

  • trac: Mercifully, I didn't have to use this much, but the learning curve appeared to be rather steep, and it was a completely alien experience from Bugzilla.

Debbugs (1)

kabloom (755503) | more than 5 years ago | (#26645471)

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.

Re:Debbugs (0)

Anonymous Coward | more than 5 years ago | (#26646217)

Anyone can subscribe to any bug they find interesting.

Debian does not autosubscribe the reporter to the bug. I don't know who made that design choice originally, but it really makes the system a pain in the ass to use. I usually just bypass debian's system altogether unless it's a packaging bug because of this issue.

Re:Debbugs (1)

dondelelcaro (81997) | more than 5 years ago | (#26647229)

Debian does not autosubscribe the reporter to the bug. I don't know who made that design choice originally, but it really makes the system a pain in the ass to use. I usually just bypass debian's system altogether unless it's a packaging bug because of this issue.

The reason why they're not automatically susbcribed is because not everyone wants to know about the process of resolving their bug; they just want to know when it gets fixed. That said, adding the ability to subscribe at submit@ time is on the todo list. [debian.org]

Re:The 2.5 I've used (1)

Avatraxiom (602424) | more than 5 years ago | (#26645557)

Bugzilla does have time-tracking, you just have to set the timetrackinggroup parameter. Products can be hidden by setting them as Mandatory/Mandatory for a group that nobody is in. You can also close them to entry and they won't appear on the New Bug page. -Max

Re:The 2.5 I've used (1)

chrisabailey (684766) | more than 5 years ago | (#26645607)

Not sure the last time you used Bugzilla but you can currently track time, entering an estimated time and updating the actual time as you go.

You can also configure when you want to get emails based on what fields change and your relationship to the bug (Originator, Assignee, or watching).

Bugzilla is the only system that I have ever "liked" to work with. I have used several commercial systems as well as several large scale home grown systems over the last 20 years. All the others were slow and cumbersome and most are based on the belief that developers can't be trusted to update the bugs appropriately. This leads to way too many controls on the developer. Bugzilla on the other hand is much better about assuming that we want to do what is best and want a system to document our progress and help communicate among the team.

Re:The 2.5 I've used (0)

Anonymous Coward | more than 5 years ago | (#26645675)

You don't have to receive all the spam from a bug... the types of messages you receive are configurable in bugzilla.

Re:The 2.5 I've used (1)

greg1104 (461138) | more than 5 years ago | (#26645791)

Trac works pretty well as an internal bug tracking system where tight integration with the version control repository is important to you. Making it easy for tickets and commits to reference one another can be really helpful. I can't imagine it would be appropriate for the situation being asked about here though.

The current Bugzilla feature list includes time tracking; I'm curious if you tried that but didn't find it adequate, or was that just added since you last upgraded?

Re:The 2.5 I've used (1)

BillAtHRST (848238) | more than 5 years ago | (#26646225)

Add scarab/collabnet to the list of junk. It seems designed solely to give PHB's (not-so) pretty reports to look at.
Sheesh -- can't even do a text search (I guess that's why God gave us eyeballs).

Re:The 2.5 I've used (3, Informative)

cca93014 (466820) | more than 5 years ago | (#26646251)

Bugzilla has "good search features"? Whenever I try and search a bugzilla database I seem to either get 0 hits or about 8 billion. Really. It's like a magic trick or something...

JIRA is the best bug tracker out there IMHO...

Re:The 2.5 I've used (0)

Anonymous Coward | more than 5 years ago | (#26647105)

Stop bitching and learn to use bugzilla's search.

Re:The 2.5 I've used (1)

shakotah (785520) | more than 5 years ago | (#26646431)

To hide products (projects) in bugzilla just make it only viewable by an "archive" group

Re:The 2.5 I've used (1)

sdguero (1112795) | more than 5 years ago | (#26646771)

I have been admin on a Mantis bug tracker that covers many projects and has tracked over 1000 bugs since it started.

It has a simpler interface than bugzilla, and I have customized the crap out of the php since we started using it 2 years ago. It is pretty easy to work with...

WTF? (1)

bwcbwc (601780) | more than 5 years ago | (#26645313)

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.

Re:WTF? (2, Insightful)

corbettw (214229) | more than 5 years ago | (#26645719)

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.

Re:WTF? (0)

Anonymous Coward | more than 5 years ago | (#26646683)

If he's working in such an enormous company, there should be some sort of integrator type person running around who should be aware of this and have at least some type of long-term plan to make all the current divisions use the same (or a couple of semi-compatible systems).

If it's a small company there shouldn't be any reason why the situation still is what it appears to be, or why it can't be changed in a relatively short term.

If you go with a commercial system, you'll probably even get them to care of the mess of inserting all the old crap into the new app which you can force onto all the teams and divisions.
It's what happend where I work, and although most of us were expecting a complete disaster and a lot more work, it went relatively smooth and only caused a bit more work for a couple of months.
In our situation it's of course just 1 company with about 50 different locations(which include acquisitions, subsidiaries and partners).
If you have to track bugs you submitted to another company it might be harder, though if you can subscribe in some way to get a reply for any change to that bug-case to a fixed adress, it should be fairly easy to get that processed automaticly at which point you could get a notification.

Post it notes on 32 inch TV (3, Funny)

theverylastperson (1208224) | more than 5 years ago | (#26645365)

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.

Re:Post it notes on 32 inch TV (1)

jechoe (414218) | more than 5 years ago | (#26645689)

If you have too many bug reports, you lose your mirror and end up focusing on fixing them to reduce your paranoia!

Re:Post it notes on 32 inch TV (1)

aztektum (170569) | more than 5 years ago | (#26646185)

My question is: When did TV's ever come with a non-glossy screen?

Re:Post it notes on 32 inch TV (1)

Eddy_D (557002) | more than 5 years ago | (#26647461)

My question is: When did TV's ever come with a non-glossy screen?

Just get a TV from someone who smokes heavily. The smoke tar does a lovely job of creating a non-gloss coating on the screen...

Re:Post it notes on 32 inch TV (1)

schneecrash (1021829) | more than 5 years ago | (#26646191)

lol.  a sony? ;-)

i think you may be the only one who "Really Read" (tm) my question ...

OhLoh (0)

Anonymous Coward | more than 5 years ago | (#26645371)

Try http://www.ohloh.net/

3 Good Apps for Bug Tracking (0)

Anonymous Coward | more than 5 years ago | (#26645417)

Mantis - open source web bug tracker
FogBugz - already described previously
Sharepoint - Part of WSS and MOSS

Re:3 Good Apps for Bug Tracking (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#26645747)

excuse me but i already mentioned SharePoint.

please read what people said before you before double posting.

I've tried a couple (1)

McBeer (714119) | more than 5 years ago | (#26645425)

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.

Tasktop (2, Insightful)

admorgan (168061) | more than 5 years ago | (#26645525)

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.

Bugzilla will be adding inter-tracker support (1)

Avatraxiom (602424) | more than 5 years ago | (#26645595)

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 [mozilla.org]

-Max

Re:Bugzilla will be adding inter-tracker support (1)

schneecrash (1021829) | more than 5 years ago | (#26646321)

now THAT's what I call "Service!".  thanks :-)

Tps reports (1)

Joe The Dragon (967727) | more than 5 years ago | (#26645641)

Tps reports

Bug Tracking is even worse than Version Control (3, Insightful)

Lord Bitman (95493) | more than 5 years ago | (#26645801)

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 (2, Insightful)

DragonWriter (970822) | more than 5 years ago | (#26645977)

Why can't anyone agree one what's "right to use"?

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.

JIRA all the way! (0)

Anonymous Coward | more than 5 years ago | (#26645853)

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.

Humans and feet (1)

neile (139369) | more than 5 years ago | (#26646553)

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

Re:Humans and feet (0)

Anonymous Coward | more than 5 years ago | (#26647705)

I read 'Humans and feet' as the subject and in this context immediately thought of [crunch] ... [squish] ... [splutch]. But alas ... you were being all practical and serious! :-/

Sanjay (0)

Anonymous Coward | more than 5 years ago | (#26646719)

The easiest thing to do is write software without bugs. Duh.

Any books on the subjec of tracking issues (0)

Anonymous Coward | more than 5 years ago | (#26646851)

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...

TFS (0)

Anonymous Coward | more than 5 years ago | (#26646983)

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...

Scrum (0)

Anonymous Coward | more than 5 years ago | (#26647023)

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.

Anonymous Coward (0)

Anonymous Coward | more than 5 years ago | (#26647431)

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 :-)

You inseNsitive cOlod... (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26647497)

will not work. And FreeBsD at about 80

Extension addressnig (2, Informative)

belg4mit (152620) | more than 5 years ago | (#26647581)

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.

If you've got issues, try JIRA! (2, Informative)

thomas.mitchell (1423413) | more than 5 years ago | (#26647719)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?