I'm trying to think of a nice and easy way to do this, but I thought I'd run it past some people for a second opinion:
Say you've got 8 clients (one project for each customer) and each project derives from a core project. If a bug is raised that has to be fixed in core, our current approach is to create a bug and clone it for each customer (using Bugzilla). A lot of developers are finding it time consuming to manually clone the bugs across all clients and ensure that they are placed on each release tracker per customer.
I suppose this is a workflow problem, so does anyone have suggestions on the best way to handle cloning bugs for multiple customers? Perhaps Bugzilla isn't the best tool for this. Most of us believe that it can not be fully automated and will require some manual intervention regardless of what tool we use.
One idea I did have was to create a single bug issue. If it is a core bug and when assigning it for one release, we don't mark it as completely resolved as it has not been tested for all client projects that stem from the core project. The problem with this is that I would need a way to link the single bug to all customers and have it know when to automatically set it to resolved once the last customer has had a release. I don't believe Bugzilla has such a feature.
Any thoughts or ideas would be welcome.
Best Answer
I don't know of an automatic feature in bugzilla for doing such (the bugzilla api is powerful, and may provide some places to script... but I'm not familiar enough with it to be certain)
But I agree that the problem seems to be workflow related... If you think about it there seems to be an almost cyclic dependency... To finish the release of the core component we require the validation of the client product, but to resolve the release of the client product the core component must be released.
Instead of worrying about every client validating a fix, what if you had feature/regression tests for the component itself (which would be updated as needed). The issue with the core component can block the release of the core component, which can block bugs for the release of each client project.
When the fix is finished and passes its feature tests, the issue bug can be resolved. When all issues have been resolved, and the component has been regression tested, the component could be released and the issue bugs can be closed. When testing is complete for the client project (including validating all of the included changes), the client release bug can be resolved.
Now as far as validation for the client projects go, this is where continuous integration would pay off immensely. The development build of each client product could be taking development builds of the core component and validating that things work, and discovered issues can be logged against the core component while development is ongoing. If an issue is found after the core component is released, then we start the process over with a new issue bug and a new release bug for the core component, blocking the client releases.
It almost feels like a release early, release often mantra if that makes sense.
Yes, this is a manual process, but maybe it'll reduces the cloning of bugs if that makes sense... not sure how if it would jive with your requirements / regulations though.