- Release Policy
- Procedure for asking to port code and OCDB entries from the trunk to the release
- Computing Rules (New)
The Alice Off-line Software will be constituted by a large amount of files, sources, binary, data and related documentation. Clear and efficient management guidelines will have to be implemented if this corpus of software has to serve its pourpose along the lifetime of the Alice experiment. These are largely independent from the tools used to put them into action. The following sections define, at the Managerial Level the policy guidelines.
The Alice Off-line Software is divided in packages. Packages will be defined empirically as a number of files containing programs, data and documentation logically related. The size and number of packages will vary during the lifetime of the Alice Off-line Software. Packages will be joined and splitted as dictated by convenience, trying however to minimise the number of changes and to preserve backward compatibility. Example of packages can initially be:
- The TPC software;
- An event generator;
- The steering of reconstruction;
- The steering of simulation;
A package will be physically contained in one top level directory with the package short name. This should be not more than 8-10 letters, no underscores, to allow it to enter easily into variable names. Packages will be installed in an open (to Alice) area on AFS (see later distribution).
Every package has a coordinator who is the only person allowed to make changes to the copy of the package installed in the public area.
The Alice Off-line Software will be available at any moment on the public directory in three versions: the previous one, the current one and the next one (old, pro and new).
Binary versions will be available for the platforms officially supported by the Alice Program Library Office. At the moment of writing these are:
- i686 PC Linux
- i686 PC Scientific Linux 4
- x68_64 Linux
- ia64 Itanium Linux
- Intel Mac
This is not a fixed list and it will evolve with time. Individuals or groups can offer to support other platforms/operating systems and in this case they have to conform to the release policy and schedule.
Alice Off-line Software will be maintained centrally by the Alice Program Library Office. He/she will be the only one allowed to make changes to the public directories for the previous and current version. The files of each package in the new area will accessible to the respective package coordinator all the time except 10 days before a scheduled release, when the Program Librarian will take exclusive control. The release will consist in the archiviation of the old version, the copy of the current version onto the old one and the copy of the new one onto the current one.
Changes to the new area will be made solely by the Package Coordinators, even if the Program Librarian has access to it. A simple scheme of protections at the directory level will support this. If a tool offers a more sophisticated control mechanism, it will be used.
Bugs and problems should be communicated to the Alice Program Library that will communicate them to the appropriate package coordinator, or they can be communicated to the package coordinator directly.
The packages and the corresponding binary files for the supported systems is available on afs. A complete distribution is also available also via ftp. The software should be able to run also on stand alone systems without any network connections, and a stand alone installation option should be present.
All the material found in this site is available subject to the following copyright:
* Copyright(c) 1998-2008, ALICE Experiment at CERN, All rights reserved. *
* Author: The ALICE Off-line Project. *
* Contributors are mentioned in the code where appropriate. *
* Permission to use, copy, modify and distribute this software and its *
* documentation strictly for non-commercial purposes is hereby granted *
* without fee, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission notice *
* appear in the supporting documentation. The authors make no claims *
* about the suitability of this software for any purpose. It is *
* provided "as is" without express or implied warranty. *
It is the responsibility of the different detector groups to maintain and develop the different modules describing the ALICE detectors. The modular structure of the code has been developed to reflect this fact, and changes in one module should not affect the others.
New modules can be provided, incorporated and tested within the AliRoot framework. These should then be submitted and incorporated into the centrally maintained filebase.
Any query or proposal for a change in the code can be addressed to the Alice Off-line Mailing List.
AliRoot Release Policy
- The code compiles on all the platforms;
- Extensive tests on Linux (Pentium, Itanium, Opteron; gcc and icc);
- No significant memory leaks (valgrind).
Release: tag with branch (every two months):
- Quality assurance:
- Test suites - simulation using special cocktail generator to illuminate every detector/reconstruction from digits; simulation with event merging/reconstruction from raw data; simulation of minimum bias proton-proton events/reconstruction from digits and raw data; simulation of PbPb events/reconstruction from digits and raw data;
- Reference data kept to test the backward compatibility;
- Valgrind - fixes for run-time errors and memory leaks;
- Profiling - gprof and VTune. The results are published and the algorithms fixed accordingly.
- Principles of the release policy:
- Announce the release 15 days before the tag;
- Postpone the functionality, not the tag;
- After the tag accept only bug fixes in the release;
- Do not move tags;
- The branch is always backward compatible. In exceptional cases send alert in the ALICE off-line mailing list one week before the changes and commit them if no major objections.
- Requests are discussed and approved (or not) at the weekly offline meeting which usually is on Wednesdays at 16:00. All requests submitted before Wednesday at noon are considered at the meeting;
If a request is not viable for technical reasons (files not compiling, or not working or missing or not in the proper format), it is simply adjourned to the following week;
Core offline reserves the possibility to make "technical fixes" (protection against division by zero and the like) asynchronously with the above schedule;
OCDB files have to be created with the framework in order to contain the correct metadata. Special attention has to be brought to the backward compatibility of the objects in the OCDB;
Files to be ported should be identified by one git revision, i.e. the files should be checked into the trunk with a single operation;
The person proposing the fix should participate to the weekly meeting, in person or via videoconference;
The fixes should be thoroughly tested and in particular they should work with the standard PbPbench and ppbench tests of AliRoot;
When coding the proposed corrections, special attention should be brought not to introduce warnings or Coding Convention violations.