Fog Creek Software
Discussion Board

Bug Tracking and Maintaince Releases

Our company is looking at improving our bug tracking process and we ran into a problem in keeping track of what Maintainance Releases bugs are fixed in.  Was wondering if you had any advice on how to resolve this problem (feel free to plug FogBUGZ!).

The crux of the problem is that at a given point in time, the defect may affect the HEAD development, and 1 or more older releases.  We may start by fixing the problem in the HEAD branch, but may wait to back-port the changes to a maintaince release.  We want to show that the defect has been fixed in the HEAD release, but SP1 still has the defect.  And we can't figure out how to keep track of that fact in any of the products we have looked at.

What approach would you suggest to keep track of this kind of situation?  Since we couldn't find any products that would give us this type of behavior, I think there is something wrong with how we are looking at the process.

Any help would be appreciated!

Bill Napier
Wednesday, March 03, 2004

Well, I suppose you could create two bugs.

One of them could be of the form

"Fix Bug 1234 in head"

and FogBUGZ would make that a hyperlink.

Joel Spolsky
Fog Creek Software
Wednesday, March 03, 2004

This is, and has always been, a tricky problem.

Problem and Change management is never as simple as some purport it to be for exactly these sorts of reasons.

Really what you need to say is; there is Problem X in this release N of the application.

Trouble is you would need to do this more than once where the same problem affects two different releases and nobody is ever going to bother with that. It's not good practice from a normalisation point of view either.

You have to think about getting the logical model right. In the example you gave you have two Problems; one with each release. There is however, once diagnosed, only one Known Error (manifesting itself as the two problems). And the error is in source code file 'fred' version 2.3 (it doesn't have to be source code - it could be something else in the makeup of the application);

If you assign the Error to the failing item-version i.e. Fred 2.3 you can easily report on what errors there are in a given release of the application (what Errors are associated with the versions of code that are built in the application). This should make sure that you don't miss it.

But then the next challenge is that it's not only Fred version 2.3 that's got the fault. It was also in Fred 1.7,2.1 and 2.2. Do we record that too? (Someone else could be using an even older version of the application and not have found the problem yet).

You could say 'no' we don't bother recording it against older versions that are not in currently supported releases of the application. And 99.999% of the time you'd be right. But every so often changes get taken back out, and we might go back to version 2.1 of Fred for some other reason, and now we've got an old version of the code that has that damned bug in it but we never recorded it.

This stuff is always a compromise and even the best problem management tools won't help you here. It is, however, a brilliant opportunity to get involved in some deep thinking to come up with your own approach and learn something in the process.

Wednesday, March 03, 2004

One problem report with two branches.  Close the Fred 2.3 branch as "fixed", close the Fred 2.2 branch as "will not be fixed" or postpone it as "to be fixed at a later date", depending on whether you're still supporting Fred 2.2.

If your bug tracking software doesn't support branches, create two bugs and link them, or create three to maintain the hierarchy.  I've never used FogBUGZ, I don't know what it can do for you.

Wednesday, March 03, 2004


Could you provide some more details on your problem?

I hope I'm not over-simplifying here, but it sounds like your problem may be a symptom of either not having a good versioning scheme for the software or (probably more likely) not having a good way of using your bug tracking software to track and document what is fixed from build to build.

If you're not already doing this, a solution would be to make sure when a task is fixed, part of the data you collect is the version number associated with the specific build/release it's fixed in.  As the other's suggested, I would recommend creating a separate task for each release the task is fixed in.

From there, it's just a matter of using the data to create Release Note reports out of your bug tracking database, including details of all of the defects fixed in that build for the release.  If you decide to fix it in only the most current release without rolling it back, you might want to include a note to indicate as such in the release notes.

Again, apologies if I'm oversimplifying.  Hope this info is of some help...

Wednesday, March 03, 2004

One more note I missed...

It also maybe useful to collect the branch the defect is found in, if you're not already doing that.  Once you have this piece of data, it would be easy to make it a habit to enter the tasks for all branches it exists in, and then you could easily get a status report out of the bug tracking system of what's fixed and open in each specific branch (even if an issue is fixed in one branch but not the other).

Wednesday, March 03, 2004

This is one of the many reasons of why I avoid branching my code whenever possible. Though I realize that there are times when you can't force customers to take the latest and greatest release.

Saturday, March 06, 2004

I think Gwyn had it right - moving toward normalization is the better path.  Having multiple cloned bugs lying around makes tracking history of the bug difficult - do all of the clones link to each other and/or the parent bug? 

I would prefer to have one canonical bug record with an array of fields indicating bug dates and states for each release.

Normalization is not an easy solution either.  I tried to find an example of how Mozilla uses Bugzilla to handle this given their myriad releases - here's a problem report that shows the complexity of grafting multiple release histories in one bug report:

I'm not sure how to parse the Whiteboard information, but it looks to be some tagging convention to indicate among other things bug state over different releases.  Yipe.

Thursday, April 08, 2004

*  Recent Topics

*  Fog Creek Home