DiscussionNotes

Notes from the discussion of the work flow for trunk updates and committee restructure

RL proposed two main roles for committee, managing trunk updates and community building/communication.

Code management issues

• During code development the trunk is updated relative to the branch where the development is occurring. GA suggested an agreed time threshold on when it becomes the developer's responsibility to update their branch development to the current trunk. Acknowledged any time would be somewhat arbitrary but needs a hard threshold.
• General agreement that benchmarking is critical, that code developments need to work in ACCESS as well as global offline and benchmark simulations/metrics need to include all major applications. There was interest in creating an agreed list of tests/metrics that code should be assessed against to be included in the trunk.
• IH noted need for some flexibility around what constitutes a pass/fail for demonstrating improved model performance - noting that a bug fix may make a simulation worse because the model has been tuned to accommodate the bug and/or has compensating errors.
• JK proposed that code could go into the trunk even if not working with ACCESS as long as code was switchable and clearly documented as not suitable/un-tested for ACCESS. Suggested that all tagged versions should work with ACCESS.
• There was general recognition that while switches were important for allowing code to move quickly into the trunk, an uncontrolled proliferation of switches was not helpful, default/preferred configurations needed to be defined and redundant code needed to be removed (perhaps through a separate ticket). Modular code is required. JS suggested a 6 monthly release cycle which would provide a pause point in code development to consolidate optional code, update configurations, better organise switches etc.
• Using working groups to help with managing code assessment for trunk may require somewhat dynamic membership and leadership. A committee role would be to manage overlapping tickets/developments and bring working groups together.
• The number and scope of working groups was discussed. There is a tension between having different working groups responsible for different parts of the code (to ensure no group is overloaded with tickets to manage) and managing tickets/issues that span different code areas. One suggestion was to have one working group for core code (i.e. those routines in the biogeophys and biogeochem directories) and one for interface, initialisation and I/O code across both offline and online applications. This merges CABLE-offline and CABLE-coupled working groups from the original restructure proposal. Given the critical need for better benchmarking, a working group focussed on benchmarking seems desirable.
• Committee may need to have a conflict resolution role when two or more code developments are not compatible. There may also be conflicts between technical and science needs.
• Technical documentation is important and is currently very out of date. Committee needs to push for adequate documentation of new tickets/code changes but we also need to work out how to resource a more general update to documentation.
• IH expressed a concern that there could be risks in ticketing too early, e.g. reporting a potential bug which turns out not to be a problem. RL suggested we would prefer to err on too early rather than too late given our history of relatively limited ticket use.
• RL raised the question of whether we should have code owners for specific routines (names are listed against many of our current subroutines). It was seen as a danger to have a single person as owner and arbiter of what could go into that part of the code - hence the need for a working group/the committee to make that decision.

Community building / communication

• 3 monthly updates of what everyone is doing would be useful. Via video?
• The ticketing system provides a mechanism for communication if everyone is using it.

---

Back to agenda/minutes