views:

174

answers:

1

Within our environment we have a core codebase, and several client-specific implementations of that codebase. When a client raises an issue, we need to determine whether it is a client specific issue, or whether it is a core codebase issue.

We use bugzilla to track our bugs, and we have a bugzilla product for the core codebase, and also for the client implementation (as they have customised the offering to have enhanced functionality). When a client raises a bug that relates to the core codebase, we need to raise that bug in 2 bugzilla products - core and client - so that both teams know about the issue. Ideally, we'd relate these bugs together so that we don't waste effort attempting to fix it twice, and so that the 2 Project Managers are fully informed of the progress of that issue.

My best idea so far is to use a comment/description including the works "Relates to bug " as it appears that the words bug magically become a link to the specified bug making it easy to get to that other bug's detail. This can then be searched for via the "A comment contains the search" criteria.

How do others do this?

+4  A: 

I would use depends/blocks fields, if they are enabled in your Bugzilla, with the following workflow, roughly:

  • a bug X in a client-specific product is filed;
  • if it is found to be present in the core product, another "core" version of this bug (bug Y) is filed in the core product, and it is made to block the client-specific bug (Y blocks X, X depends on Y);
  • core team proceeds to fixing core bug Y;
  • when core bug is fixed, then client-specific bug X can also be fixed (it may or may not require additional effort).

The benefits of using depends/blocks instead of links in comments are:

  • notifications: when someone changes bug Y, everyone who's watching bug X will also get notifications;
  • enforcements: Bugzilla can be tuned to disallow closing bugs that depend on at least one open bug, so Y will have to be closed before X is closed.

We used to have a similar setup, with one core product and two production products that get shipped to customers. However, we had a single team for all products, so it's simpler. A bug was usually filed in a production product, after which we either fixed it there, or escalated it to the core product, or made a duplicate bug for the other production product. Whenever two bug records were there for the same problem, they were linked with depends / blocks.

sereda