9.6. How to relate issues to problems in dependencies
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.
