ACCESS Model Release Workflow

PROPOSAL, Not Current Practice

Release Types

Technical Releases are less strictly defined releases, and may reflect a work in progress shared among a small audience.

Final Releases are fully tested configurations released to a wide audience, with an accompanying submitted paper (such as the ACCESS CMIP releases).

Release Workflow

1. Create a Proposal ticket

Create a new ticket on the Accessdev Trac system for your proposal, with the following settings:

Your NCI user id
Model Releases
Research Leaders Group representatives, see below

The ticket title should be your proposed release name, and the description should provide a brief overview of what the model configuration is and why it would be useful to the community. This ticket will track the life of the proposal as it's created, reviewed and then released to the community.

When you create the ticket you should CC your institution's ACCESS Research Leaders Group science and technical representatives, who will work with you to bring the proposal to the RLG for in-principle approval

Science: Christian Jakob cxj565
Technical: Scott Wales saw562
Science: TBD
Technical: Mike Naughton mjn548
Science: Tony Hirst ach599
Technical: Martin Dix mrd599

2. Document the Proposal

Once you have in-principal approval from your RLG representatives to create a release you will need to write some documentation to describe your proposed release. Create a wiki page for the release documentation by adding a comment to the ticket like:


replacing <<name>> with your release name. This can be a hierarchy if there are multiple related releases, with the scheme Configuration/Resolution/ModelVersion e.g. wiki:ReleaseProposal/GA6/N96/UM10.2.

With the comment created you should be able to click on the link to go to the wiki page. Create the page, using the ReleaseProposal template. This will give you a questionnaire asking you to describe the model, which other users of the release will be able to go to to get more information.

3. Review

The release review process is a means to check that your release proposal is sufficiently documented, all the branches are tagged in the relevant source repositories and that it's usable by researchers in other projects. The review is conducted by someone separate to the release developers in order to get a second opinion.

Once your documentation is complete ask your RLG representatives to assign the ticket to a reviewer. The reviewer will fill in the 'ReleaseReview' questionnaire linked on the documentation page, and ask you to fix any outstanding issues.

4. Release & Communication

Once the review has been successfully completed you can ask the RLG to approve your release. Once they do your RLG representative will:

  1. Add a link to your release documentation to wiki:Releases?
  2. Notify the community of the release through the access_users mailing list
  3. Resolve the ticket as 'fixed'
Last modified 6 years ago Last modified on Nov 3, 2015 3:26:03 PM