12.8. How to relate issues to problems in subproducts

ArgoUML uses products internally and is very dependant on that these products are functioning well. This are products like GEF, NS-UML, ocl, log4j, xerces, jre, ...

Occasionally a problem found in ArgoUML is found to be a problem in one of these subproducts and cannot or is extremely complicated to fix within ArgoUML.

If this happens this is the way to handle this problem.

This can be performed by any member of the project (any role). There might be special skills involved depending on the nature of the problem. In this description "issue" means a issue in issuezilla, "bug report" means a bug report in some other project, and "problem" denotes the conceptual problem.

Do the following:

  1. During your examination of an issue you find that the problem is in one of the ArgoUML subproducts (GEF, NS-UML, ocl, jre, ...).

  2. Make sure that the issue is assigned to you.

  3. Write a comment in the issue stating which one of the subproducts that has the problem (and what the problem is within that subproduct).

  4. Post a bug report in that subproducts bug reporting tool (or find that a bug report already registered).

    I am assuming that there is such a tool for the subproduct in question. If there isn't, then make the bug report to the person responsible for this product so that we are sure that the problem is communicated.

  5. Accept the issue (set it to STARTED) and enter the reference from the subproducts bug reporting tool and if possible the URL to the bug reporting tool or to the bug report in question.

    I am assuming that there is a bug reporting tool for the subproducts. If there isn't for the product in question, then include all communications (both ways) in the issue.

You are now responsible to follow up on the upcoming releases of the subproduct. If you don't think that you are the best person for this (you should be since it was you that found that this problem is in the subproduct), assign the issue to "the right person". To follow up you should do the following.

  1. Look at each new release of that subproduct to see if the bug report is in fact stated as fixed in that release.

  2. If the bug report is fixed, then you weight together the importance of the problem, other bug reports that are also problems in ArgoUML that are solved in that release, the amount of work needed to fit the new version of the subproduct instead of the old one, the planned releases of the subproduct with promises to solve other bug reports, and the current release plan of ArgoUML. From this you decide wether it is time to do the update of the subproduct within ArgoUML or to wait.

  3. If you decide that it is time to update, you assign all issues against that subproduct to you (if not already), then you do the work. The work is to add the new version of the subproduct to ArgoUML, do all the needed work within ArgoUML to fit the new version, test and commit everything, put the issues indeed fixed in RESOLVED/FIXED, and close the bugs registered in the subproducts bug reporting tool.