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