Official cvs repository: structure, use and access control



The repository shall consist of 2 main areas:


1) official ATLAS software

        fully ASP-compliant or `ramping-up'


2) external software


and if absolutely necessary at a later stage a 3rd area for contributed ATLAS-specific software















  • official ATLAS software



    • Packages are official in the sense that they are endorsed by the offline software community as the obey or are being upgraded so as to obey the standards set in the context of the ASP.


    Each package has one single package responsible/coordinator. Access control is established: the coordinator (and the team he nominates) as well as the librarian and the support team have commit access to the repository.
















  • external software

    • Packages in the repository are mainly of the shareware type e.g. software downloaded from an ftp site. The procedure for their acceptance is defined in the ASP.

    Each package must have a single coordinator, responsible for maintenance and support.

    The packages cannot be local copies of officially supported external software. Such packages can only be included if there is a clear and well justified need for ATLAS-specific modifications ratified by the original package coordinator and an expert team as well as the DIG.

    External users of packages shall need only standard languages and compilers to use the products. All packages must build on all supported platforms and must provide standard interface for the librarian (as defined for the official software). They also have a well-defined life-time i.e. obsolete, unmaintained or unused packages are reviewed and removed from the repository.




  • contributed ATLAS-specific software

    • Packages have been written by ATLAS collaborators and are clearly and unambiguously ATLAS specific.

    Their inclusion is discussed at the appropriate forum in the presence of the software team members (likely to be) directly affected (usually the librarian and in controversial cases the sw coordinator).

    The packages have to use `standards' in terms of languages, compilers and libraries i.e. a package cannot import its own parser, require a specific non-supported compiler etc. In particular, external users of packages shall need only standard languages and compilers to use the product.
    All packages must build on all supported platforms and must provide standard interface for the librarian (as defined for the official software).
    They should be accompanied by a README file summarising their purpose and status and giving pointers to their documentation (if necessary).
    They cannot be part of the official software or local copies of it. They are `single' packages i.e. they cannot import the source code of any external software they may be using.
    They have one single coordinator, typically the author and no official support is guaranteed.

    They have a well-defined lifetime i.e. obsolete, unmaintained or unused packages are reviewed and removed from the repository. Access control lists can applied or modified at any time, especially if a package causes conflicts with the official software in which case access is restricted to the package coordinator until the conflict is resolved.

    For simplicity the FORTRAN software could use the same areas with the following conventions:

    1) official = 98_2 release and subsequent cvs updates

    2) external = none

    3) contributed = none