This document details the repository access policy for CCSM and all components in the CCSM repository. Issues like overall repository structure, access, and testing requirements are presented.
The following policies should be applied to the CCSM model and all components of CCSM. It is recognized that individual components have different needs and concerns, and that slight variations in policy may be required for each component. In addition, there may be distinctions required between scientific development and software engineering development. However, there shouldn't be any distinctions between internal and external developers. This policy attempts to balance the needs of the individual developer with the needs to the overall community.
CCSM uses Subversion as a tool for source code control. Development occurs only within specific component directories. Within each component directory, there is one main trunk and multiple branches. Branches can be created from any point in the repository and branches can be merged together at any point in the repository. In general, development can occur on the main trunk or on branches. Under this policy, development on CCSM by external collaborators is allowed only on branches. The trunks are reserved for formal component releases (staged, internal, or external). A released version is created by merging changes from the branches onto the main trunk. This is done by the component gatekeeper. Under no circumstance should any external developer commit changes to the main trunk.
Branches will be created in the repository at the request of an
individual or group of developers with approval of the appropriate
working group and/or change request board. Developers will be
responsible for making sure their branch stays up to date with
releases on the main trunk. Coordination between branches within a
component is the responsibility of the developers working on those
branches. Before a developers branch is merged onto the main trunk,
the developer must make a request to the change review board, the
component must pass certain testing and validation criteria, the
developer must show scientific or software benefits, the branch
version must be consistent with the latest release on the main trunk,
and the change must be approved.
In the CCSM repository, access can be limited to a particular
component. Within a component, individuals are granted specific read
and/or write permission for specific tasks, on specific branches,
and/or over specific time periods. SVN usage by individuals will be
monitored and if terms of the access policy are violated, access will
be terminated.
Only allowed to read from a given set of CCSM component
directories. The read-only access extends to the main trunk and
specific branches only. No other branches should be accessed for this
access level.
Only allowed to read and write from/to specific branches.
This also entails read-only permission to the main trunk.
Access will be terminated if any terms of the access policy are
violated. To remain in good standing, developers should make regular
use of their access privileges. If an account is inactive for more
than 6 months, access can be terminated. Developers should provide
regular updates on development progress to the appropriate working
group. Participation in CCSM working group meetings is
recommended.
Access will be terminated if any terms of the access policy are violated. Repository usage will be monitored. Individuals will be granted read and/or write permission in specific areas of the repository, generally limited to particular branches. If a developer either writes to the main trunk or accesses a branch (either via read or write) not specifically granted, access will be terminated immediately and a review of the developers actions will follow. This includes but is not limited to activities like
Developers are allowed to create branches off their own branches and
are allowed to work on multiple branches and update or merge codes
from other branches as long as permission to access all those branches
has been formally granted. All developers will be granted read access
permission to versions on the main trunk and merges from the main
trunk to the development branches are allowed and encouraged.
The source code from the repository will only be used for the agreed
upon code development project. Source code from the repository may
not be used for any projects outside the scope of the agreed upon
project.
Developmental releases of the CCSM generally contain still unpublished
changes to the model so that developers can combine their changes and
attempt to understand both the physical and software interactions. No
code should be copied from developmental releases for other purposes.
Generally, code will not be shared with anyone else including CCSM
collaborators and participants. Generally, all developers must obtain
permission, agree to these conditions and check out the code
themselves. Developers can share development branches as long as it
has been approved as part of the access request and is coordinated
through CCSM procedures. An exception to these rules is made for
individuals that are developing code under the direction of someone
that has repository access; they are working on the same tasks as
those described in the repository request; and their work is
supervised by the primary developer.
Configuration management procedure are laid out in the CCSM
developers guide as well as within individual component model
groups. You should remain up to date with changes in the developers
guide and be in regular contact with the software engineering
component liaison. Component liaison contacts will be included in
the email granting repository access.
It is recognized that many scientists are involved in activities with
models other than the CCSM and that many proposed improvements will
have been tested elsewhere. This activity is encouraged, as is the use
of portions of publicly available CCSM versions in other
models. However, code may not be extracted from developmental versions
of the CCSM for inclusion in other models. Anyone wishing access to
use code which is not in the current public release should contact the
individual developers directly. Similarly, it is expected that only
the original developers will extract code from other models for use in
the CCSM.
There will be formal testing requirements for work on branches. In particular, these requirements will be set by each component individually and may include items like
Test criteria and scripts will be available to all developers. In general, development versions must be up to date with the latest version on the main trunk and must pass specific tests before merging changes on to the main trunk will be considered.
Naming conventions will be set by each model component separately. These naming conventions must be followed.