[evla-sw-discuss] Re: meeting Nov 7 2005 (code management)

[Doug Tody]

I noticed this interesting discussion of code management in the ECD meeting
announcement.

>From Barry:
> I would like to see something closer to the AIPS
> paradigm, in which there is a TST version and a STD version, and maybe
> an OLD version, and in which there is also provision for loading private
> software.
>
> I think the TST equivalent is the nightly compile.
>
> STD can be either a periodic update (currently once a week), or can
> be a regular release with a new release being made when a set of defined
> features is ready to go.
>
> I think an OLD version (the previous STD) is worth having.  It can, of course,
> be recreated from the repository, but being able to get to it at a moment's
> notice is worthwhile.  (On the VLBA correlator we even have an OLDER, which
> to the best of my knowledge has been loaded exactly once, in a decade of
> operation.)

For what it is worth, what is described here is similar to what we did
for IRAF and for configuration management of the observing software on
Kitt Peak.  We always had at least three versions, development, released,
and at least one "old" (the previous release).

In the observing systems generally only the standard/released version
was used, although sometimes particular observing programs would swap in
a custom version of the system.  In the case of IRAF (the desktop) all
three versions were installed on the servers and a user could run any of
them, e.g., they might continue to run a given version for a time even
after a new release, in order to have a stable environment to complete
some reduction program.

We did not use CVS, but if we had, what we would have done was cut a release
by checking things out of CVS, and using this for the build/test/deploy.
In the case of the observing software the system was strictly configuration
controlled, running the released version of the system.  A new release was
tested via simulators (including a simulated full-system test in the lab
we called "astronomer testing", performed by the instrument scientists)
and then in an engineering run on the telescope, before being used for
normal production observing.  When installing a new release the current
release was moved to "old".  We generally used either symbolic links or
environment-controlled startup files to switch between versions, allowing
one to quickly fall back on the previous release in the event of problems.

Our configuration control was such that essentially no one (except the
operations staff) was allowed to touch the installed production software
at the telescope, except possibly for runtime configuration files which
were designed to be modified.  Bugs were fixed by producing, testing,
and installing a formal patch release.  Our experience was that some form
of configuration control was essential to have a reliable system.

	- Doug