ArgoUML uses products internally and is very dependent on these products functioning well. This are products like GEF, MDR, OCL, log4j, ...
Occasionally a problem found in ArgoUML is found to be a problem in one of the dependencies and cannot be 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:
- During your examination of an issue you find that the problem is in one of the ArgoUML dependencies (GEF, MDR, OCL, ...).
- Make sure that the issue is assigned to you.
- Write a comment in the issue stating which one of the dependency that has the problem (and what the problem is within that dependency).
- Post a bug report in that dependency bug reporting tool (or find that a bug report already registered). I am assuming that there is such a tool for the dependency 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.
- Accept the issue (set it to STARTED) and enter the reference from the dependency 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 dependency. 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 dependency. 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 dependency), assign the issue to "the right person". To follow up you should do the following.
- Look at each new release of that dependency to see if the bug report is in fact stated as fixed in that release.
- 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 dependency instead of the old one, the planned releases of the dependency with promises to solve other bug reports, and the current release plan of ArgoUML. From this you decide whether it is time to do the update of the dependency within ArgoUML or to wait.
- If you decide that it is time to update, you assign all issues against that dependency to you (if not already), then you do the work. The work is to add the new version of the dependency 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 dependency bug reporting tool.
For dependencies that are not delivered with ArgoUML (JRE, Xerces, OS, drivers, HW, ...), the same process is taken except that the issue is solved when it is entered into the ArgoUML FAQ or documentation or in some cases as tests in the code testing that we are not using that version. At that point is resolved (as RESOLVED/FIXED).
The rationale for this is that we, the development team, help the user to the right version of these by the FAQ and documentation and by code testing the versions.