BooNE Code Management Policy
The Code Management Working Group has been charged with making a
recommendation to the collaboration as to what Code Distribution System
(CVS or UCM are the likely candidates) we wish to use as a collaboration.
However, such a decision must be made in terms of a code management policy.
The purpose of this document is to suggest such a policy.
Code Management Group Members
General Philosophy
In general, all code, data, documentation, and results should be available to
all members of the collaboration. While open access is important, not
all items need to be distributed in the same manner. For example, results,
papers, and plots may be available on a general web site while data can
be distributed as tapes or over the internet. Thus, while we will take
a very general view in what we consider "code", it will not be all inclusive.
In addition to an open access policy, we want
every member of the collaboration to be able to work on any portion
of the code. While this will
obviously need coordination with other members working on the same
elements, we want this coordination as simple as possible to encourage
as many people to contribute.
Types of Code
The following we will consider as possible candidates for "code":
- Programs (in the language of choice: Fortran/C);
- Scripts (shell scripts, Perl, Awk, etc.);
- Makefiles;
- Short Documentation (README, INSTALL, etc.);
- TeX files;
- Kumacs; and
- Electronic logs.
The following are not candidates for code management (because
they are either too big, machine dependent, or not really compatible with
a sequential update philosophy that most code managers use):
- Graphics/.ps files;
- Hbook files;
- Data files; and
- Detailed documentation.
Minimal Rules of Code Management
While no one likes rules, some rules are necessary to simplify the process
of code distribution and development. The folloewing are our proposed set of
minimal "rules":
- Only Unix platforms will be supported. While some items (like
.tex files) may run on other platforms, we will only support Unix conpatible
system. We will also assume that standard Unix tools are available on
the platforms. Assumed tools include:
- Cernlib
- CVS
- Tk/Tcl
- Perl/Gawk/Gmake
(This list will grow as code and needs develop.)
- Code will be distributed as source code. We anticipate that a wide
variety of platforms will be used for this experiment. Thus each platform will
have to make its own executeable. The ability to distinguish among
platforms must be built into the compilation procedure.
- Committed code must run on a "standard" machine. This machine will
presumeable be a Lab E machine of some sort.
- Each institution will be responsible for modifying the platform
dependencies in the code to be compatible with their environment. While
we expect to set standards in the future that will make migration from one
platform to another easier, we expect that some things will have
to be done on a case by case basis. These additions are the responsibility
of the institution.
- Each product will have a "contact person." The responsibilities
of this person will be to:
- act as a resource for people beginning to use the product;
- police/regulate additions to the product; and
- define releases.
The contact person for each product will define how much/little control
he or she wishes to exert over the product.
Duties of the Code Management Working Group
The code management working group members will take on the following tasks:
- Suggest to the collaboration which tools (including which code manager)
should be considered standard for the collaboration.
- Become the contact person for their institution for the code management
software.
- Become the collaboration's consulting/testing group when specific products/procedures are requested as standards for the collaboration.
Version 1.2
Version History:
1.0 - 7/13/99 - Initial Version - R. Johnson
1.1 - 7/14/99 - Add Peter and Andrew; remove C++ - R. Johnson
1.2 - 8/17/99 - Slight modification; add new standard products.