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. YPW suggesting that could be two (mostly separate) groups doing these two tasks with separate coordinators - see attachment below.

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.
• 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). JS suggested a 6 monthly release cycle which would provide a pause point in code development to consolidate optional code, update configurations etc.