Multiple bug reports for a single problem

[Tom Emerson]

John P. Fisher writes:
> We have several branches of code in CVS. Frequently an issue arises that 
> needs to be fixed on multiple branches, but can't all be done at the same 
> time, because of dependencies or contractual issues. (At present we use an 
> old, modified ver of Bugzilla based on 2.13.) Our workaround is to file 
> multiple bug reports with similar summaries.
> While I think this workaround is theoretically adequate, though inelegant, 
> it turns out it fails due to lack of discipline and enthusiasm. To put it 
> differently, its a PITA so the developers don't do it. Further, it tends to 
> fall between the duties of Test and Development.

We have had a similar issue here: multiple products or components
sharing a similar bug.

The way I "solved" it was to create a project called "Meta", into
which the "master" bug is filed. Then separate bugs are filed against
each project and set to block the master meta bug.

To make this easier to stomach for people, I wrote a command-line
script that would handle distributing the 'meta' bug to the other
components and setting up the appropriate dependencies. Hence they
just had to create the meta bug, then run the script specifying which
components should be dependent on it. This could have been added to
our Bugzilla installation, but I've tried to avoid making local
customisations as much as possible.

> Bug reports would have the concept of siblings - bugs not dependent yet 
> similar.

This is almost something else: I've often though it would be useful to
have another category of bug relationship that isn't hierarchical but
more of a "see also". 


-- 
Tom Emerson                                          Basis Technology Corp.
Software Architect                                 http://www.basistech.com
  "Beware the lollipop of mediocrity: lick it once and you suck forever"