Using the ACCESS Trac System

• This should end up as a set of guidelines for using Trac tickets to track changes, targeted at developers & support for all components of ACCESS

• For tickets to be useful any guidelines should be as low overhead as possible, we don't want to dissuade users from using tickets and svn.

• The difference between using tickets in trac and the access_help helpdesk should be clear to developers and users

• It's probably going to be infeasible to have people following multiple trac ticket lists, they should end up in a central place (eg trac/access)

• Tickets should enable easier tracking of collaboration with external agencies, eg. Met Office by logging what changes have been forwarded upstream

Why create tickets?

Using tickets for changes to the core model (should mainly be the dev/Share branches in UM code, trunk for locally developed models e.g. CABLE) should allow us to keep track of rationale for any changes that may affect scientific results, as well as making sure that all developers are across any changes that might affect users

Who should create tickets?

Tickets should be created by developers for any changes to common branches or the trunk (eg. fixing a bug, upgrading versions). General users could use the tickets for collaborative code development on a branch or to request changes be added to the core model, though I'd expect that normally they'd make such requests through the NCI access_help system.

What should tickets include?

Bug report tickets should include at the very least a description of the problem, descriptions of the expected & found results and how they differ and what version of the code the issue was found in.

How should tickets be resolved?

Issues should be resolved by making note of the commits that fixed them and whether that fix will affect science results for future runs. If relevant fixes should also be forwarded to external parties, e.g. the Met Office collab team for UM issues & correspondence should be recorded in the ticket.

• Should branches be used for fixes changing science results?

• Should we have others review code before committing changes?

Suggested changes to the current setup

• Set up the trac system so that people can be emailed on ticket creation & resolution

• Configure the access trac site to hold tickets for all access repositories

• Configure trac & svn so that commits can reference tickets in commit messages

http://collab.metoffice.com/twiki/bin/view/Support/CollaborativeCodeDevGuidelines http://collab.metoffice.com/twiki/bin/view/Support/CodeDevelopment