A.M.Jonckheere
                                                        3/7/96

                   Minimum Code Management Requirements

    A combined D0/CDF/CD group has been/is being formed to address try to
develope a common code management (code configuration) system. From D0 the
members are Qizhong LI-DEMARTEAU, Herb GREENLEE and Alan JONCKHEERE. The
hope is that we will be able to arrive at a common code management system
that the CD will then support and maintain. Undoubtably there will be parts
of such a system that will be application (experiment) dependent enough
that we will have to write and maintain it. But if the system is well
enough designed with hooks for such experiment dependent pieces built in,
then this task might not be too large.

    We need to be able to clearly express our minimum requirements for such
a system. We have already agreed that we need:

1) Many versions of each library or module should be available at all
   times. Each one tagged in the archive with it's unique version number.

2) "Product versions" will be maintained which tie together compatible
   library versions. When a given executable is verified to work, a list of
   all of the component library versions will be created. A utility which
   allows the user to pick out a particular product version, and all of
   it's components will be supplied. The user will be able to specify a
   product version, override one or more component versions with his/her
   own choice and override any specific files from any of those to link
   and/or debug custom or standard executables. 

    ie) LIBUSE D0RECO-V12-20        ! V12-21 is CURRENT
        LIBUSE MUON_UTIL-V4.6       ! but use a newer version of MUON_UTIL
        then BUILD the D0RECO executable using the standard BUILD routines.
        Optionally, the user should be able to add in code of his/her own
        without having to edit the BUILD procedure.

3) Official Releases should be done centrally from the archive site to a
   small number of "standard" platforms which have well defined
   characteristics such as manufacturer, operating system version,
   compilers and their versions, graphics packages and their versions etc.
   Releases need to be done "fully" automatically, which means that library
   specific build files must be created as part of the release.

4) Distribution should be done to remote sites by "pulling" from the remote
   site. Most distribution problems need to be handled from remote end
   anyway. Distribution should be done in two forms:
    a) Binary distribution to those sites with compatable systems.
    b) Source code only with a semi-automatic rebuild at sites which are
       not fully compatable. These would use the same build procedures that
       the original release uses.

5) Test releases should be done by each library's czar using the same
   release procedures, but with a single fixed version number for that
   library. (MUON_UTIL_T for example).

6) Code verification would be done in several parts:
    a) At code entry into the archive a procedure would be run that
       verifies that the code meets at least minimal standards. At the
       least it must compile without errors on the most restrictive of the
       standard platforms. More???
    b) At release time, it must at least compile on all standard platforms
       and, if any executables are built, they must build and run (?) on a
       small test data set without errors on all platforms.
    c) Periodically, a full verification for "correct" results using a more
       extensive test data set(s) would be done. It is this verification
       that would trigger a "product version" creation.

7) It must be possible/easy to retrofit any or all versions with necessary
   bug fixes.