This page aims to explain and make accessible to everybody the integration procedures used by the ITS team. We will discuss:
Note that the same information can be found scattered in different documents, in particular the "Guidelines" and the file in the ITS CVS area: ITS/Docs/Cookbook.
By the 15th of every month, the subsystems
developers are supposed to archive in CVS the ICD/<SUBSYSTEM_NAME> software
with the tag
MONTHLY-YYYY-MM
where YYYY is the four-digit
year number and MM the two-digit month number
By the last day of every month, the subsystems
developers are supposed to archive in CVS the <SUBSYSTEM_NAME> software
with the tag
MONTHLY-YYYY-MM
Where, again, YYYY is the four-digit year number
and MM the two-digit month number
By the last day of every month, the ACS and ARCHIVE
developers are supposed to archive in CVS the <SUBSYSTEM_NAME> software
with the tag
ACS-n_m_p-pre-YYYY-MM
where n is the major number
of the ACS release, m the minor number and p the patch level; YYYY and MM
as for the other integration types.
ITS
will perform the 3 integrations every month. A particular case is when an
ALMA SW release is being prepared. In this case, ITS has
got two months to make everything work. During the two months, subsystem developers
should be available for bug fixing when required by ITS. (In principle, ITS
does not need monthly tags during the two-months integration time, but it
is recommended as a good practice, that the code is tagged
For
each type of integration, it can happen that problems are found so one integration
cycle is not enough. Patches to the tagged software are required and new integration
cycles have to be performed.
In
case of required bug fixing(s), one or more patches to one or more subsystems
are delivered to ITS with the special tag
MONTHLY-YYYY-MM-i (for ICD and monthly integration) or
ACS-n_m_p-pre-YYYY-MM-j (for the ACS-ARCHIVE integration).
(i and j are integer from 1 to …)
ITS has the task to try out those patches again in another (one or more) integration
cycle.
At
this point it is crucial to be able to distinguish among the different integration
cycles. For this reason, ITS retags the subsystems software in CVS with a
special tag and this operation is repeated by ITS every time there is a new
patch to try out in a new integration cycle.
The
special tag can have three possible formats (where g is an integer running
from 1 to …):
Let’s
make an example, for the sake of simplicity with 3 subsystems only.
We
have to integrate <s1>, <s2> and <s3>.
The
first iteration (ITER 0) for the month of September 2004 we simply retrieve
the 3 subsystems with the tag MONTHLY-2004-08 and integrate.
Then
let’s suppose that <s1> needs a bug fixing which is provided as MONTHLY-2004-08-1.
We
first retag the software of the 3 subsystems in CVS
<s1>
MONTHLY-2004-08-1
<s2>
MONTHLY-2004-08
<s3>
MONTHLY-2004-08
with MONTHLY-2004-08-ITER-1 and then retrieve the tag MONTHLY-2004-08-ITER-1
and integrate.
If
then another integration cycle is necessary because <s1> provided another
patch and <s3> as well, we will retag the software:
<s1>
MONTHLY-2004-08-2
<s2>
MONTHLY-2004-08
<s3>
MONTHLY-2004-08-1
with MONTHLY-2004-08-ITER-2 and then retrieve the tag MONTHLY-2004-08-ITER-2
and integrate. And so on until the
software is stable.
In
case of an ALMA SW release preparation, for example R2.0, we would retag the
subsystem software with R2_0-ITER-1 and R2_0-ITER-2 etc. Once
the integration is finished and the software is stable, the software will
be released and will be given a final tag like ALMA-R2_0.
Garching
During
a monthly integration (for example for the software tagged MONTHLY-2004-08
by the last day of August) the work explained in the previous paragraph will
be done within the first 15 days of the following month (1-15th
of September in the example). Then the results have to be published and by
the 16th of the month the ICD integration should begin.
The
ACS-ARCHIVE integration can last longer, till the end of the month (26th
of September for the software tagged, for instance, ACS-4_0_0-pre-2004-08).
We stop the integration a little bit before the actual end of the month, because
developers should have the time to merge the patches into the main trunk,
tag and test the software for the following integration.
Socorro
Socorro
will perform the monthly integration of the subsystem software, following
the same mechanism as in Garching, in the Prototype
Software Integration Lab (PSIL). The monthly integration in the PSIL can last
longer than in Garching and can continue till towards
the end of the month. Patches can be required by ITS in Socorro after the
15th of the month, these patches should basically involve the CONTROL
and CORRELATOR subsystems. The integration work in the PSIL will be stopped
5 days before the end of the month (in the example around the 26th
of September) to give the developers the time to merge and test the patches
into the main trunk and tag for the following monthly integration.