[evla-sw-discuss] Distribution

[Barry Clark]

Since we are getting to the point of wanting antenna 14 to join test
observing regularly it is time to think about distributing software
updates.  This is necessary, because when an operator comes on shift
at midnight, and something doesn't work, or, maybe doesn't work, if
the software is infinitely mutable, he should call out both a software
guy and a hardware guy.  But if he knows the software is the same as
last week, it narrows his options considerably.

OTHER NRAO SOFTWARE SYSTEMS

VLA on-line software has, from time immemorial, had a monthly software 
update cycle.  Before the cuttoff time, programmers submit the changes 
they have ready for that month, and the software is compiled and frozen 
until next month.  

VLBA station software ran on the same cycle, until, approaching
maturity, with little programmer time going into this software, it 
dropped to an 'on demand' basis.  

VLBA correlator started off on a monthly basis, then changed to a 'defined 
features list' basis.  That is, a list of features for the next update 
was composed, and programmers were requested not to commit software beyond 
that point.  When the features were present, the software was frozen, 
tested, and installed.  This was the most economical way to handle it 
because of the extensive regressive testing Steve Blachman insisted on 
before installing a new release.  The correlator system has the nicest
implementation of distinguishing versions:  there is a programer's
'personal' version, which he can request be loaded, the 'new' version,
made by the nightly compile of committed modules, and the 'code' standard
production version.  There are in addition, 'test', where frozen 
software is held while the regression testing is being run, and 'old',
the version of 'code' from the previous release.

AIPS has an annual release.  But, in addition, a constantly updated version
is available via the 'midnight job'.  If one is concerned that the software
not change in the middle of ones project, one uses the annual release.
If one is more concerned with having the latest features, one runs the
midnight job to import them.  This way of doing things is very appropriate
for data processing software, where bugs or misunderstood features cost
only a bit of user time, not observing time.

sched has an 'defined features list' release system, as does jobserve.

WHAT SHOULD BE COVERED BY A RELEASE SYSTEM

The important thing to cover is the real-time software.  In our curren,
Maven oriented, organization, this includes the OBSERVE project, but also
the EVLA/COMMONS project, and possibly the NRAO/COMMONS project.  MIB
software should be generally included, but a higher revision MIB might
be installed in one place on a trial basis without confusing things too
much.  The eventual code for TELCAL and for DCAF should be under the
release system.

Screens should be under the release system in a curious fashion:  one
should usually get the nightly build version of screens, so that newest
features are available.  But the released version should also be available,
so that if an operator gets confused, he can go back to something familiar.

obs2script should be covered, as it is basically part of the real-time
system.

The COMMONS areas present particular problems, as other users of them 
may have different release/distribution requirements than the real-time
system.

RECCOMENDATIONS

I think we should go to a monthly release system now, with the first 
release coincident with the next Modcomp release date, June 15.  This
would cover OBSERVE, EVLA/COMMONS and obs2script.  TELCAL and DCAF would 
be added to the system as soon as they hit the repository.

For mechanism, I recommend the following for java components:  Maven
makes things like evla-observe-0.2.jar.  Every month, Maven would be
told to increment the release number by .1.  Then, we would have 
symbolic links that point to the appropriate jar.  For instance, if
at some update time we are going from release 0.11 to 0.12, then
we would in a directory called 'nightly' create a symbolic link
evla-observe.jar -> ../evla-observe.0.12.jar
and in one called 'release'
evla-observe.jar -> ../evla-observe.0.11.jar
and in one called 'old'
evla-observe.jar -> ../evla-observe.0.10.jar
with the result that one gets self-consistent current, released, or 
previsouly released software just by chaning the base address of the 
jars.  Selection of this can easily be built into the execution scripts.

Similar sorts of arrangements can be made for C executables.