Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Bug Programming Technology

Bug Tracking Across Multiple Code Streams? 33

Posted by Cliff from the one-bug-many-branches dept.
Eric Lennon Bowman writes "I've been using Bugzilla for a few years, and it has one particular shortcoming that is motivating me to look for alternatives. We very often find that a bug or feature requires changes to be integrated into several code branches, and there just isn't an elegant way (that I can see) to get Bugzilla to do that, short of creating a bunch of bugs, and linking them together as dependents (which is a bit inelegant, and error prone). I'd love the opinions of the Slashdot community on ways to deal with this problem, since it seems pretty widespread: How do you track the same bug across multiple versions of a product?"
This discussion has been archived. No new comments can be posted.

Bug Tracking Across Multiple Code Streams? More

Bug Tracking Across Multiple Code Streams?

Comments Filter:

  • DevTrack (Score:4, Informative)

    by djwavelength ( 398555 ) on Thursday October 06, 2005 @09:31PM (#13736109)
    DevTrack [techexcel.com] allows you to generate multiple sub-issues automatically based on a value of the original issue, such as platform. You end up with several sub-issues to fix/validate the bug on the selected attribute. You can then link these in parent/child relationships. Its not free, but it works well.
  • "How do you track the same bug across multiple versions of a product?"

    Fix it as soon as it's reported!!!
  • I merely make sure there are no bugs in my code to begin with. :P
    • the whole point is that how do you track bugs that were not _your_ bugs?

      it's pretty unlikely that you wrote _everything_ your app links to and that it would be independent of anyone elses code.

      unless you write 500 byte arkanoid clones or something.
      • Your brain is too small to understand.

        Please visit Disney.com [disney.com] until you are old enough to: a) Understand IT, particularly programming b) Get a sense of humour c) Trick your friend's grandma into taking your cherry.

  • Universal bug tracking. That's the goal of the Malone [canonical.com] project. And yes, it's sorely needed.

    • Re:Malone (Score:1, Informative)

      by Anonymous Coward
      Universal bug tracking. That's the goal of the Malone project. And yes, it's sorely needed.

      I agree, it sounds like an excellent idea. Except that after following your link, it doesn't seem to be out yet. Or am I missing something?

  • newer bugzilla (Score:5, Informative)

    by norwoodites ( 226775 ) <pinskia@ g m a il.com> on Thursday October 06, 2005 @10:50PM (#13736490) Journal
    Use a new bugzilla and the clone feature.
    GCC has no troubles handling this problem.
    For bugs which are only need to be fixed on a release branch, the summary is marked with "[x.x only]" and the target milestone is set.

    This is not rocket science.
  • I thought that's what Canonical's Bazaar was all about? Mark Shuttleworth wants a bug-tracking system that will allow people to propagate a bug from the Ubuntu package to the Debian package to the upstream mainainers, all with minimal hassle and a central interface.

    http://bazaar.canonical.com/ [canonical.com]

    • Mark Shuttleworth wants a bug-tracking system that will allow people to propagate a bug from the Ubuntu package to the Debian package to the upstream mainainers, all with minimal hassle and a central interface.

      While he's at it, maybe he could look into - I dunno - propagating a buffer overflow, or maybe even propagating a full-blown backdoor r00t?

  • A quick and easy method for mozilla is to first create a bug for each module/branch/file (whatever you like) affected. Afterwards, you create a bug and mark it "meta" or whatever you like to name it (in the summary field; of course you could also create an alias). Then you link all the bugs created in the first step to this meta bug by adding them to the "depends on" field.

    Et voila, you only have to track the meta bug now, and the issue is resolved after and only after every bug the meta bug depends on has

  • Too many forks... (Score:1, Funny)

    by Anonymous Coward
    ...makes spoon jealous.

  • Re: Bug Tracking Across Multiple Code Streams? (Score:4, Insightful)

    by glob ( 23034 ) on Friday October 07, 2005 @01:29AM (#13737250) Homepage Journal
    > How do you track the same bug across multiple versions of a product [in Bugzilla]

    there's a few ways ..

    what i generally recommend is created a new bug for each version (bugzilla's clone feature helps lots here). the reason why i suggest this you should expect the actual code changes to be different with different versions of your code.

    if you're using bugzilla to track code reviews and testing, then you really *have* to have seperate bugs to manage the full process.

    normally i'd create a bug against the main version, and then clone it to cover the backported patches. cloning automatically puts a "clone of bug NNN" as the default comment 0 (or words to that effect). i don't use dependancies to track the links across versions.

    another method is to use bugzilla's flags. create a set of flags such as "fixed in version 1", "fixed in version 2", and set them where appropiate. personally, not a fan, as it make generating reports on things like average time-to-fix difficult to generate.

    another option is to code up the ability to switch "version" and "milestone" files from single to multiple values, and submit the bug back to bugzilla.

    -byron
  • The small company I work for uses an in house bug tracker, developed in a fit of "eat our own dogfood". Admittedly, it is missing a lot of features of off the shelf bug trackers, but it serves our specific needs. One feature it has, is that it separates Issues (bug reports) from Tasks (the development tasks that are needed to fix them). Multiple tasks can be associated with an issue. So our normal procedure is to enter issues as the reports come in, marking them as New. Then the development manager goes t
  • Mantis Bugtracker ( http://www.mantisbt.org/ [mantisbt.org] ) handles this as follows:

    1. A user reports a bug.
    2. The developer identifies that the bug applied to other branches.
    3. The developer clones the bug, which automatically creates a copy of the bug and allows the developer to edit it before it gets submitted. The user edits the version to which the issue applies.
    4. The created clone automatically gets a child relationship with the original bug, but this can be changed as part of the editing done in step 3.
    5. By do
  • Do it just like you'd do it in CVS: create a BZ product specifically for the core/common codebase, in addition to the specific focused products. In that way, bugs that lie in in the common component or library (etc.) go into the common-code product.

    So if you've got a central server component that a dozen actual products use, create a Core Components product with a "CoreServer" (or whatever) component, or a "product" specifically for that "CoreServer" component, and assign it by default to someone who works
  • Too bad we don't sell it anymore, but IBM CMVC is great at this sort of thing.

  • I'm glad to see someone else raise this point. It was part of a discussion I led last week at the Software Development Best Practices conference in Boston, and also appears in my new O'Reilly book "Practical Developments Environments" ( http://www.oreilly.com/catalog/practicalde [oreilly.com]). Enough of the plugging, here's my take on the problem. I've done both #1 and #2 and want to see someone do #3.

    1. Most people clone or link multiple bugs together to represent the bug in each release. This seems heavyweight, and m

  • We're using BUGS [sourceforge.net] at work.
    It may not be as feature complete as Bugzilla or other but this feature is built-in as you can see here [sourceforge.net]
  • ClearCase for source control and ClearQuest bug tracking. Makes it easy. Better have money though.

Slashdot Top Deals

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Close