ESMA Git Policy

Management Policy for the ESMA Git Repository

This document is to establish firm policies for the management of the ESMA repository under Git. For now we are just collecting various thoughts/opinions about existing practice that must be addressed by the document. After some accumulation, I’ll attempt to provide some structure for further refinement.

It is also worth noting that GFDL has a significant amount of documentation about aspects of their policy that might serve as good starting points for elements of our own.

Topics

• Roles
  • User
  • Developer
  • Gatekeeper
  • Administrator (superusers)
  • Committee for approving changes to this document

• Regression testing
  • Including how to evolve the regression tests
• Branch and release naming/tagging
• Externally shared components
  • MAPL
  • FV3
  • FMS
  • ...
• Issue tracking and monitoring
• GitHib/Bitbucket/GitLab - which repository management service to use and who hosts the service? One option would be for GMAO to host its own Bitbucket server.
• ??

NCCS Issues

This may not be the ideal place for these issues, but we can collect them here while we fill this document.

• iNode limit

  Git use may increase the typical number of filesystem iNodes used by developers. OTOH, it may not, as users may be able to use a single clone to manage multiple versions of the software rather than independent CVS checkouts. Either way, it would be useful to engage the NCCS to ensure that a suitable file system is made available for GEOS development.

  • backup requirements
• testing infrastructure

  Ideally commits to key branches will be contingent upon passing agreed-upon regression tests. Computing resources for this could be large. It is anticipated that the NCCS may need to make some system modifications to enable such testing in an unattended manner.

  • Jenkins launching batch job
  • Git host pushing test request
  • Fast turnaround for first level of tests.