Skip to content

WorkFlow

Jump to bottom
rml599gh edited this page May 10, 2017 · 5 revisions

Work flow for trunk updates using the trac ticketing system

  1. Tickets should be used to report bugs, code improvements, code deletions and new code developments.

a) Bugs are defined as a code change that is required to correct a mistake in the code. Leaving the old code in place is not appropriate.

b) Code improvements are defined as pieces of code that provide an alternative to current code. To facilitate early adoption in the trunk, the alternative code should be put under a switch. If the code performs better than the original across a range of applications, a new ticket should be created to propose removal of the original code and the switch.

c) Code deletions are defined as pieces of code that are no longer required as the application is obsolete or an alternative piece of code has been shown to be more reliable or efficient.

d) New code developments are defined as those pieces of code that add new capability to CABLE. New developments should be on switches. A complex new development should be broken into multiple tickets for more efficient trunk approval, with an overarching ticket to describe how the parts come together.

  1. Each ticket should report only one issue for easier trunk approval.

  2. Tickets should be opened as soon as the bug is noticed or the improvement/development work begins. Tickets should include

a) A description of the bug, improvement or new development and whether it impacts core science code or offline interface code or ACCESS coupling code.

b) In the case of a bug, whether the impact of the bug has/will be assessed by the reporter or not.

c) In the case of an improvement/development, the person/people who will be working on that improvement/development.

d) The branch that has been set up for the work to be done in, and the name of the switch that will be used.

  1. Each committee meeting will include a ticket review

a) New tickets will be assessed.

b) Any tickets that report a small change that has been sufficiently documented and tested may be immediately approved for inclusion in the trunk.

c) Most tickets will be allocated to the appropriate working group (core science code, offline interface and I/O, ACCESS interface) for assessment and monitoring.

  1. Working group assessment of tickets should include

a) Identifying potential conflicts with other in-progress tickets

b) Checking coding standards [automated as per Met Office?]

c) Ensuring documentation is adequate

d) Confirming that code change passes Jenkins-based technical integrity tests [including no impact when switch is off]

e) Reviewing impact of code change across applications [as provided by developer in collaboration with key users??. Need benchmarking tests as part of Jenkins suite]

  1. When a working group is satisfied that a ticketed change meets all requirements, the ticket is returned to the committee for approval to be implemented into the trunk

  2. Trunk is updated by the technical coordinator and ticket is closed.

ISSUES / QUESTIONS:

  • Trunk is updated while another development is in progress. Whose responsibility is it to keep up to date with trunk? Developer?
  • How do we want to handle changes that have impacts across code e.g. where initialisation is handled differently in offline and online?
  • What size working group is desirable, 2-3 people of whom at least 1 needs to be a committee member?
  • Is this the right set of working groups?

Back to agenda

Clone this wiki locally