1

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.

Improve this question
8
  • 2
    Could be a dumb question but when you say 'core' do you mean a shared component that is used by all 8 clients, or code that has been duplicated and modified for all 8 clients?
    – Charlie
    Apr 2, 2011 at 21:27
  • 1
    Do you have your core as a seperate component?
    – user1249
    Sep 4, 2011 at 11:26
  • @Thorbjørn Ravn Andersen - Nope, core is a shared component. So the package structure would be like com.companyname.core.blah and then the client specific stuff would be com.companyname.customername.blah. All the customer/code code is packaged into a single SVN project and using filters in eclipse/ANT, we filter out the customers we don't want to deal with.
    – Desolate Planet
    Sep 4, 2011 at 13:20
  • 1
    A separate component inside bugzilla so all customer deployments depend on this core component?
    – user1249
    Sep 4, 2011 at 13:28
  • 2
    I think it is a fundamental problem of shoehorning a real life thing into the abstractions provided, and getting it wrong. The frequently way to handle releases is to make a "You can report issues against these things", not making it an issue it itself.
    – user1249
    Sep 4, 2011 at 14:08

2 Answers 2

Reset to default
1

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.

Improve this answer
1

You may be confusing CRM with software issue tracking. Reports from user/clients should be researched against a knowledge base and then triaged and moved upstream if not resolved with that. It's what companies with thousands to millions of clients do.

  1. If the triage of a failure points to the core, create an issue for the core, and tag the issue for the client with the core issue's id.
  2. If other clients haven't reported the same issue, and the issue is not severe (business-wise, legally), then stop at this point. If they do report it, then register an issue like before, against the same core issue.
  3. If the bug will get you or your clients in trouble, then notify your clients by any means, telling them about the risks, and when you expect to have the problem solved and in their production environment.

Yes, It is a work-flow issue.

The approach you are using could be refined to avoid duplication if the issue went to a CRM system as a single instance that got updated when the problem in the software issue base was closed.

Again, imagine you had a million users, and that a hundred of them reported a problem. What would you do? Set up a process that costs a K*10^6 or one that costs M*10^2?

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.