Slashdot Mirror
Bug Tracking Across Multiple Code Streams?
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?"
DevTrack 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!!!
"Derp de derp."
I merely make sure there are no bugs in my code to begin with. :P
Quando Omni Flunkus Moritati
Universal bug tracking. That's the goal of the Malone project. And yes, it's sorely needed.
How we know is more important than what we know.
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/
Our small but growing startup is using Fogbugz , an excellent bug tracking tool. It is integrated with our subversion repository, and I have nothing but high praise for its ease of use and feature set.
Fogbugz easily solves this dilemma. To restate, the same bug is present in multiple revisions, and it must be fixed in each one.
One bug is created describing the problem. The bug's is marked as present in one of the revisions, and the text of the bug includes which branches/revisions it is present in. As each revision/branch is fixed, the bug is changed in the 'fix-for' to the next revision, and a comment added with info on the remaining branches to be fixed.
I would suggest to the Fogbugz development team (headed by Joel Spolsky ) that it is possible to handle this even better by allowing multiple revisions to be selected for the 'FixFor' pulldown, and then thereafter allow these to be unchecked or added to as need be.
Otherwise, the existing Fogbugz will work just fine. I can't speak to Bugzilla, but it might have a technique as well.
Unitarian Church: Freethinkers Congregate!
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 been resolved.
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
...makes spoon jealous.
> 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
nostrils
Where's the code?!?! Where's the free software licence???
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 through them periodically (sooner if a customer is breathing down his neck), and assigns one or more Tasks to the issues, marking the issue as Active (the issue can also be marked as Duplicate or Rejected at this stage). If there are two active development branches, generally there will be two Tasks assigned to the issue, the developer then knows to merge their changes into both branches, and the testers treat the tasks as entirely separate, since they're generally testing one version at a time.
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?
Mantis Bugtracker ( http://www.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 doing the above process it is easy to keep track of the branches that the bug applies to, in which ones it was fixed, the modifications done in the code (if your soure control tool is integrated), and the bug summary appears also in the auto-generated change log of these branches.
The above achieves the power of tracking the issue on each branch with minimal overheads on the developer.
Please visit 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.
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 closest on that component. Then enter or move bugs for that core component into that BZ product.
Terrorists can attack freedom, but only Congress can destroy it.
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). 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 may lead to bug numbers changing for each release, which could confuse customers.
2. Other people add more fields (ToBeFixedIn_1, ToBeFixedIn_2, ...). As was pointed out, this makes generating reports painful.
3. What really should happen is that some application has to keep track of which build the bug appeared in, which build it was discovered in, and how each build is related to other builds. A picture would look like a tree with branches for each release. The key is to assume that a bug still exists in the all builds and branches after it is discovered, until confirmed not to exist.
With this information, you could ask the key question "which build or releases does this bug exist in?". Fixing the bug in a certain release updates this information. It's doesn't seem too much more work, except that when you create a new branch, you have to associate the new builds with the branch.
We're using BUGS at work.
It may not be as feature complete as Bugzilla or other but this feature is built-in as you can see here
ClearCase for source control and ClearQuest bug tracking. Makes it easy. Better have money though.