Fog Creek Software
Discussion Board

Tracking bugs through multiple dev branches

I am kind of surprised nobody else has brought this up yet but...

As we develop our product we have multiple active development branches simultaneously. Say we have a large account, customer A, that is using V1.1 of our product and we are contractually bound to support them on that version for 5 years. During that time we develop and release version 1.2 and are now beta cycling 1.3, and developing 1.4. The nature of our software also requires us to correct critical defects in 1.2 and release patches to these older versions without our customers having to move up to the full next release.

Now, customer A reports a bug they need corrected. What we need to do is target the bug to be corrected on V1.1 as soon as possible, target the same bug to be corrected in V1.3 by next beta, and to be fixed on head branch V1.4 prior to the next code freeze leading to the 1.4 release.

The bug could be fixed in V1.1 in a day and off to the tester, but the PR should also be owned by the developer for V1.3 and V1.4.

To illustrate:
PR: #1
Memory leak in system allocator whenever a chunk aligned on 64byte boundaries is returned to the system.

Branch      State            Owner                Priority
V1.1        Test-Confim  Cust A                High
V1.3        Fixed-Test      Tester Bob          High
V1.4        Open              Developer Kipp  Med
So this pr is in the Test-Confirm, Fixed-Test, and Open states. Is owned by the originator to confirm and close, the tester to test and the developer to fix.
This provides solid bug tracking capabilities and provides customers a level of confidence that for their NEXT project they can move to the later versions with confidence their one off fix was not lost and only exists back in their customized version 1.1x.

I've been looking for a PR management system
that offers such features... still with no luck

Another comment,
When a PR is marked as a duplicate, the referenced PR, the open one, should inherit the priority of the now duplicate one.  This is to prevent priority inversion of PR's.

Consider this:
Customer A notices popping in your products audio playback, but they're using your product only to display images. So they file and non-critical, low priority type PR. Sort or a "by the way, I noticed this" type bug.
Customer B building an audio device based on your software files the same bug (duplicate) that needs to be Critical High -- they can't ship their product till you correct the audio issue and their timelines may be tight.
The original open PR NEEDS to inherit the CRITICAL HIGH status of the duplicate PR.

Thanks for listening.

Everything else looks great though. :-)

Darrin Fry
Wednesday, December 4, 2002

I also would like to see support for multiple branches. We are facing exactly the same problem, and ensuring that the bugs have been fixed in all branches is quiet a hassle at the moment...

Daniel Gehriger
Sunday, December 8, 2002

*  Recent Topics

*  Fog Creek Home