Status on multiple branches

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Status on multiple branches

Nick.Barnes
This discussion of release notes interests me, as it is tangentially
related to features of the P4DTI Perforce/Bugzilla integration, and
extensions to that integration which we have built for clients.

This is the an underlying weakness in Bugzilla: that it has a single
"status" for a bug.  The fix for a single bug might be simultaneously
unnecessary (WORKSFORME) in 1.5, completed and verified (CLOSED/FIXED)
in 1.6.3, undergoing QA (RESOLVED/FIXED) in 2.0, in development for
2.1 (ASSIGNED), and awaiting analysis for 3.0 (NEW).  On the 1.6
branch it might be present in 1.6.2 and fixed in 1.6.3.

A common way to handle this in Bugzilla is to raise a separate bug for
each branch on which the underlying defect is present, and make a
meta-bug for the defect itself which depends on those separate branch
bugs.  This is somewhat unsatisfactory, and there's no UI support for
it out of the box.

An even more common approach is to keep the information in the heads
of the developers, or free-form in comments on the bug.  This is even
more unsatisfactory.

In custom Perforce integrations based on the P4DTI, we have been
working on automatically generating this branch/release status
information from the Perforce SCM (which allows one to mark a
particular atomic change as changing the status of a given defect
record).  Then we present a table in the Bugzilla bug showing the
status on each version branch of interest.  And we can generate
reports showing the bugs present in each release and on each version
branch.  We are intending to extend this work to allow Bugzilla
queries on it (e.g. "what bugs are open in this version branch but not
that one?"). Some of this work could, in time, move into Bugzilla
itself (in particular, the idea of multiple development streams, and
that a given bug might only apply to some subset of these streams, and
have a different status on each).

We use a system similar to this in order to automatically generate
release notes for the P4DTI itself from our defect database (Perforce
jobs).

This is related to the Bugzilla concepts of "version" and "milestone",
of course.  It's not entirely orthogonal to either of those, but
neither is it identical to them.

I'd welcome more discussion of this subject.

Nick B
_______________________________________________
mozilla-webtools mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-webtools