Processes to finalize

Pull Requests

1. What testing should be done prior to making a pull request?
   • aux_pop_MARBL is the only test suite we have at the moment
2. Is any additional testing needed before accepting pull request?
3. How do we make sure enough eyes see the code before accepting?

Enforcing coding standards

1. NAG doesn't allow lines to exceed 132 characters - there is a branch on mnlevy1981/MARBL (with a pull request submitted to bring it back to master) that has a script that checks for lines exceeding this maximum, maybe we should add it as a commit hook? Or at least provide it so users can run the check themselves?
2. CESM supports five compilers: intel, gnu, pgi, NAG, and cray. I don't know if ACME supports any additional compilers (IBM?), but we need to verify that code builds on all those platforms (spoiler alert: pgi doesn't work). For developers that don't have access to all those compilers, how do we enforce this?

Update to this: I am going to create a new [public] github repository that contains a suite of scripts to check various measures of code consistency. At that point, I'll update both this wiki page and the main MARBL readme with instructions on how to set up precommit hooks in local checkouts of MARBL - this will make it so that git will not allow you to commit code that violates specific guidelines (such as the 132 character limit). It seems harder, but potentially not impossible, to also have these checks run before accepting any pull requests in github.

Interface design / Documentation

1. What should the interface between GCM and MARBL look like? (Or maybe interfaces?)
2. How will the interface(s) be documented / shared with the public?

Public release repository?

1. Do we want a public-facing repository to push releases to? I'm thinking of something similar to the MPAS set-up, where code stays on the private development repository until it has been written up and submitted for peer review.