Forgot your password?
typodupeerror
Bug Communications

How To Track the Bug-Trackers? 174

Posted by timothy
from the and-what-if-they-have-a-bug dept.
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!)."
This discussion has been archived. No new comments can be posted.

How To Track the Bug-Trackers?

Comments Filter:
  • by CompMD (522020) on Wednesday January 28, 2009 @05:23PM (#26644819)

    A Jira of Jiras.

  • Basket (Score:5, Funny)

    by Tubal-Cain (1289912) * on Wednesday January 28, 2009 @05:25PM (#26644843) Journal
    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.
    • by TaoPhoenix (980487) <TaoPhoenix@yahoo.com> on Wednesday January 28, 2009 @06:05PM (#26645507) Journal

      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.

    • by darkpixel2k (623900) <aaron@heyaaron.com> on Wednesday January 28, 2009 @07:00PM (#26646273) Homepage

      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.

  • 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: (Score:3, Interesting)

      by An dochasac (591582)
      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 (Score:5, Funny)

        by lymond01 (314120) on Wednesday January 28, 2009 @06:47PM (#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!"

  • by The Dancing Panda (1321121) on Wednesday January 28, 2009 @05:32PM (#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.
    • 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 (Score:4, Informative)

    by RockMFR (1022315) on Wednesday January 28, 2009 @05:33PM (#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.
    • by Matheus (586080)

      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 (Score:5, Insightful)

      by corbettw (214229) <corbettw&yahoo,com> on Wednesday January 28, 2009 @06:08PM (#26645539) Journal

      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.

      • by Otto (17870)

        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 an

        • by corbettw (214229)

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

          A hypothetical one, obviously.

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

          One that refuses to happen while your watching.
      • jello dancers (Score:5, Interesting)

        by epine (68316) on Wednesday January 28, 2009 @09:04PM (#26647833)

        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.

  • KnowledgeDNA (Score:3, Informative)

    by doroshjt (1044472) on Wednesday January 28, 2009 @05:33PM (#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.
    • Well, *every* bugtracker software does that, including the OSS ones.
      Redmine, trac, MantisBT, googlecode, launchpad, Jira, Bugzilla, to name just a few.

      It's not quite a unique selling point.

  • 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 prog

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

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

      • 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,

        • DAG = Directed Acyclic Graph [wikipedia.org]

        • Re: (Score:2, Funny)

          by daveime (1253762)

          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

  • by geekoid (135745) <dadinportland@yBLUEahoo.com minus berry> on Wednesday January 28, 2009 @05:35PM (#26645021) Homepage Journal

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

  • Simple... (Score:4, Insightful)

    by kmsigel (306018) * on Wednesday January 28, 2009 @05:48PM (#26645235)

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

    • Re:Simple... (Score:5, Insightful)

      by pongo000 (97357) on Wednesday January 28, 2009 @06:08PM (#26645541)

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

      • Re: (Score:3, Interesting)

        by kmsigel (306018) *

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

      • Re: (Score:3, Insightful)

        by Malc (1751)

        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 produ

    • by corbettw (214229)

      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.

    • by sorak (246725)

      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... (Score:5, Insightful)

      by Chirs (87576) on Wednesday January 28, 2009 @06:52PM (#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.

      • by kmsigel (306018) *

        You are absolutely correct. I have the luxury of being the only person who has worked on this project since its inception 17 years ago. When a bug is reported, I can usually figure out what is causing it within 5-30 minutes. In a similar amount of time it is usually fixed.

        A large multi-programmer project is very different.

      • 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,

    • by Onymous Coward (97719) on Wednesday January 28, 2009 @07:03PM (#26646307) Homepage

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

      • by kmsigel (306018) *

        While true, that's not the point. ;)

        The point is that a focus on writing excellent code in the first place and then fully understanding and fixing bugs when they are discovered results in a much better product. I don't think many organizations stress *fully* understanding all observed behavior.

        Far too many programmers see things that make them say "huh, that's odd" and then never investigate. I'm not sure whose fault that is (the programmer's or management's) but it is a serious problem. In my 20+ years of

        • "Fully understanding something always pays off in the long run."

          The managerial problem being that in the long run we all are dead and it doesn't matter.

          That means that sometimes it's a better strategy not to wait for the long run to recover your pays off and avoid the expenditure right now, even if that means a dirty hack instead of a solution solidly founded on understanding.

          • by kmsigel (306018) *

            I believe that "the long run" is, at most, a couple of years. If your application is a prototype, or a proof of concept, or something you are building to convince some VCs to fund your idea then you may be right.

            If you are building something that will be used for many years, will evolve over those years, and must be very reliable during all of those years then I believe that the best thing to do is to have a very strict "everything must be understood" policy.

            • "If you are building something that will be used for many years, will evolve over those years, and must be very reliable during all of those years then I believe that the best thing to do is to have a very strict "everything must be understood" policy."

              Your policy seems reasonable. It's only reality shows otherwise. Just two examples:
              1) Facebook: they could hold till they understool what their bussiness case was, what was the best technology to achive their well understood goals, plan for hugh scalability

    • by SLi (132609)

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

      Do you have any clueless users?

    • by gknoy (899301)

      The problem the OP has is not with bugs in their own code, but in bugs in the code that they depend on. Their team is not (ostensibly) responsible for fixing the bugs, they just need to know when/if they are. Now, Open Source makes that more of a stretch, but it's entirely conceivable that one's software could depend on non-free code (or be built in a framework) which they have no modification ability for. At that point, it's important to be able to know the status of that that file I/O bug, or inability

    • by Nevyn (5505) *

      Sorry, but "fix all submitted bugs" is just not possible, unless you are using a different definition of some of those words than everyone else. Or more likely you get a very limited set of bug reports, for whatever reason.

      For a start the difference between a "bug" and a "feature" is non-existant to any normal user, so your code would have to be Skynet to not have any bugs. Also almost all users will have no idea how much work a bug entails, so you tend to have reports of "make application play alert soun

      • by kmsigel (306018) *

        You are correct; I do not get bug reports directly from users. They are filtered through people who are very knowledgeable about the product. That said, any actual bug is always sent to me. I define a bug to be crashing or any obviously bad behavior as well as a feature not behaving how we claim it should. "Make application play alert sound when Foo happens" is not a bug, it is a feature request.

        We get very few actual bug reports, and when we do get them I almost always fix them within a day or so of receiv

        • by Nevyn (5505) *

          Because it's been a long time since my view of what a bug is would meet that definition. Almost all bug trackers have priority/severity/whatever markings ... so that the very small number of bugs that fit into your category can stand out. On all but the very worst software those are "always empty" as you describe, but they account for probably somewhere between 0.01% and 1% of the actual "bugs".

          To a user everything that doesn't work as they want it to is a bug, some of the things you can easily argue are

  • The 2.5 I've used (Score:5, Informative)

    by Scareduck (177470) on Wednesday January 28, 2009 @05:51PM (#26645287) Homepage Journal
    • 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.
    • 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 ups

    • 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
    • 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 a

    • by greg1104 (461138)

      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 (Score:4, Informative)

      by cca93014 (466820) on Wednesday January 28, 2009 @06:59PM (#26646251) Homepage

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

      • The trouble with Bugzilla search with a large database is that you have to use the 'advanced search' to narrow your query, but you have to know alot about the product you're reporting against to use it effectively.

        It would be neat if the big pile of basic search results had nice drill-down tools.

    • by jeffstar (134407)

      this isn't a bug tracker so much as a task & time tracker but I can't live without clocking it [clockingit.com] now

  • by bwcbwc (601780)

    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 con

    • Re: (Score:3, Insightful)

      by corbettw (214229)

      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.

  • by theverylastperson (1208224) on Wednesday January 28, 2009 @05:56PM (#26645365) Homepage
    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.
  • 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 (Score:2, Insightful)

    by admorgan (168061)

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

  • Tps reports

  • by Lord Bitman (95493) on Wednesday January 28, 2009 @06:26PM (#26645801) Homepage

    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: (Score:3, Insightful)

      by DragonWriter (970822)

      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 centra

    • by skeeto (1138903)

      One project that really seems like it is going in the right direction is Ditz [rubyforge.org], a decentralized issue tracker. Now that decentralized version control is becoming popular, there are a handful of decentralized issue trackers being built (other are cil, git-issues, and others whose names escape me). None seem to be very usable yet, and all are experimenting on what works best.

      If you are looking for some kind of git-like breakthrough in bug tracking, that's where I would look.

  • 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

  • Extension addressnig (Score:3, Informative)

    by belg4mit (152620) on Wednesday January 28, 2009 @08:41PM (#26647581) Homepage

    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.

  • 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 co
  • 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-m
  • 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!).

    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.

  • 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.
    • "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 do. It was just installing, about half a day to mildly understand its underpinnings and except for the odd "can you please add a new component" zero maintenance. It is not that it's perfect (it's focused on the "technical" side forgetting totally about the "managerial" part and, of course, it's unability

      • by khanyisa (595216)
        Hear hear. Trac's nifty integration of wiki syntax into every field and the ability to easy cross-reference wiki, revision control, and tickets make it a winner for me.
      • You may want to take a look at redmine which many consider to be "trac done right".

  • 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 ve

  • 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
  • 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 wil

  • I'm a big fan of rt3 ( http://bestpractical.com/rt [bestpractical.com] ).

    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.

Money doesn't talk, it swears. -- Bob Dylan

Working...