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?
4. We should design a pull-request template (and maybe a commit log template as well); see issue #45

---

On the plus side, we do have a strategy for making new tags

1. Make sure master and branch to merge are up-to-date on local machine
   1. This includes making sure the current master has been merged onto the branch
2. Merge branch onto master
   • Given (1i), there should not be any conflicts to resolve; the resulting master will be indentical to branch
3. Make new tag
4. Push master and new tag back to NCAR/MARBL
5. [optional] delete branch (locally and / or from github)
6. [temporary] Make new SVN tag in CESM dev repo (necessary until CESM users have access to NCAR/MARBL on github)
   1. Make sure you have checked out master
   2. Update the ChangeLog with git log > ChangeLog
   3. Make sure any new files you have added to git have also been added to SVN (similarly, svn rm files that have been deleted from git)
   4. commit to SVN repository
   5. make new tag. Note that git tags are marbl[X].[Y].[Z] and SVN tags are MARBL[X]_[Y]_[Z]

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.