Bug Tracking: How Do You Do It?
This quote from OpenJDK Infrastructure Roadmap resonates with me:
…they had considered something like that but that the blocker was the lack of a mechanism to have a fix target multiple releases.
Suppose you have trunk, 1.9, 1.10, and 1.11 branches. Customers use the software at all of those release levels (except for the trunk, of course), and critical bug fixes are often ported to numerous different branches. Most defect tracking tools do not support this, or do so poorly.
Speaking in general terms, a “classic” bug tracking tool has a core record with a name like “Issue” “Change Request” or “Defect”. Whatever you call it, the concept is generally the same. The Issue probably has attributes such as status (new|in progress|fixed|verified fixed), priority, responsibility, synopsis, and several other attributes.
The workflow might go like this:
- Someone reports a bug.
- You create an Issue, setting the Reported Against attribute to 1.10, since that is the version the customer uses.
- A programmer fixes the problem, marking the Issue “fixed”.
- The Issue goes to QA for testing, etc…
I already have questions about this workflow:
- In which branch did the programmer commit the fix? 1.11? trunk?
- Once the Issue is marked “fixed” (assuming in trunk), how do we backport to other branches?
If a customer on release 1.9 calls up and reports the same problem, can you easily do a query and say “Yep, looks like that is fixed in version 1.12″ ?
Do you create new Issues for each and every branch you apply the fix to? That seems wasteful. But the original Issue is already marked Fixed.
One Idea
Perhaps the original Issue report shouldn’t have a Status at all? Maybe, instead, each Issue has a list of one or more “Work Request” records? Each Work Request belongs to a particular software release level, and each Work Request has its own status.
One issue might have three Work Requests: trunk, 1.10, and 1.11. You can then do a query to determine the issue is Fixed in trunk and 1.11, but not yet backported to 1.10.
How Do You Do It?
I’m very interested in learning how other companies handle this. Do any defect tracking tools support status tracking for multiple software branches, or do people just make copies of defect reports for each and every branch?
This could be easily implemented using the tag-based Google Code project hosting issue tracker.
Personally, I use Jira and the “affect versions” “fix in versions” are multi selection box.
But for workflow purposes like you expose here we lazily: Copy “and link” the issue from branch to branch.
There may be a better way, but that’s OK with us, since we use the subversion integration and so backporting to previous version need to be a different commit (so a different issue number).
@Michael how would tags accomplish this? Each branch of code needs its own workflow as an issue is first assigned to a branch, the developer marks it fixed (but just in that branch), and then QA tests. Are you saying we create families of tags for each release level of the software? Wouldn’t the number of tags get quite big over time? Where I work we have at least 30 projects being tracked by the same tool, with each project sometimes having independent branches. That’s a lot of tags.
@Fred: that’s pretty much what we do. We create new issues and link them to the original. In the end we have a graph of related issues, which “sort of” works, but has problems. For one thing, a lot of the metadata about each issue (description, synopsis, etc) is duplicated with each issue copy. The second big challenge is writing queries, because now we have to write graph traversal algorithms to produce decent reports.
I’m the author of a free open source bug tracker, BugTracker.NET (at http://ifdefined.com/bugtrackernet.html). BugTracker.NET also lacks a natural way of handling your scenario.
At work we use MKS as our tracker. We use a feature - I don’t know if it is built in or custom - called “Create Related Issue” which both clones the original and creates a relationship between the two. The cloning, though, is TOO complete, because it also clones the status of the original. So, if it is fixed in one branch, and we want to clone the issue so that we can get started on another branch, we would really want that cloned issue to start off in “New” status. If you wanted to answer the question, is it fixed in all version?, you would have to find the bug and follow the chain of links, like a linked list. There’s no one master place where you could see the parent issue and all the child versions.
Historically, what has been the problem at our company is that we think that version 3 is going to replace version 2, so we only fix the bug in version 3. Then, version 3 gets canceled and delayed and we act all surprised thinking we fixed the bug, only to realize we fixed it in a version we never released. So then, long after we did the original fix in version 3, and maybe long after the programmer who did that fix has left the company, we return to version 2. We don’t have an easy way to ask the question, “what fixes in version 3 have we *NOT* ported to version 2″.
My own BugTracker.NET doesn’t have a clone feature, so in that way it’s even worse than MKS. But, regarding the ability to view the relationships, you could add a custom field to it, “parent”, and then make all the links to the different versions go between the parent and the version. The query system is super configurable, so you could create queries that showed the parent/child relationship, that showed what fixes were done in one version but not the other.