Bug Tracking Across Multiple Code Streams? 33
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 (Score:4, Informative)
Obvious advice means karma! (Score:2, Funny)
Fix it as soon as it's reported!!!
Quite simple, really (Score:1, Funny)
Re:Quite simple, really (Score:2)
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.
-1 Clueless (Score:1)
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.
Malone (Score:2)
Re:Malone (Score:1, Informative)
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?
Re:Malone (Score:1)
newer bugzilla (Score:5, Informative)
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.
Re:newer bugzilla (Score:1)
Re:newer bugzilla (Score:2)
Canonical's Bazaar (Score:2)
http://bazaar.canonical.com/ [canonical.com]
Propagate a bug or propagate a bug-fix? (Score:1)
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?
Re:Propagate a bug or propagate a bug-fix? (Score:2)
This has nothing to do with a bug fix, with often can't be automatically propagated up and down the codestream.
Re:Fogbugz Solves This (Score:1, Funny)
Re:Fogbugz Solves This (Score:3, Interesting)
What are you trying to patent?
Easy Bugzilla Solution (Score:1)
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
Re:Easy Bugzilla Solution (Score:1)
The original article does NOT talk about the meta bug. It talks about chaining the bugs together linearly. A meta bug intread links the bugs as children of it, which creates a different topology
Too many forks... (Score:1, Funny)
Re:Too many forks... (Score:1)
Re: Bug Tracking Across Multiple Code Streams? (Score:4, Insightful)
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
Separate Tasks from Issues (Score:2)
Mantis Bugtracker (Score:1)
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
Core product vs. sub-products (Score:2)
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
IBM CMVC (Score:1)
One bug, multiple releases - a proposal (Score:2, Informative)
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
BUGS - The bug genie (Score:1)
It may not be as feature complete as Bugzilla or other but this feature is built-in as you can see here [sourceforge.net]
Rational Products (Score:1)