-
Notifications
You must be signed in to change notification settings - Fork 64
CCPP Framework Meeting Minutes 2024 05 13
Courtney Peverley edited this page May 13, 2024
·
3 revisions
Attendees: Mike Kavulich,
CCPP Framework (issues, PRs, discussions)
-
Constituent updates PR#549
- A few minor comments from Dom, but ready for testing otherwise?
-
Add support (and tests) for optional arguments in ccpp_prebuild PR#552
- Now ready for review
-
Add script to check fortran vs metadata without a host model PR#558
- Just waiting for re-review from Steve?
-
Handle dimensions for promoted variables PR#562
- Some questions from Steve, needs another reviewer as well
Standard names (issues, PRs, discussions)
- CCPP Framework development cycle
-
Discussion on Issue 553
- Proposal 1: development branch in addition to main
- Preferred option from CGD group
- Tagging needed? On main or on develop?
- Who will initiate PRs from develop to main, and when?
- Proposal 2: Forking for individual apps
- Less desired option from CGD group
- Proposal 1: development branch in addition to main
-
Discussion on Issue 553
Meeting time survey: https://whenisgood.net/r45txw7
CCPP Framework
- Highest priority PR = #552
- Dustin to review; possibly Michael K
- Scheduled in queue for this week
- Dustin to review constituents PR
- Metadata checker script
- Has been used, but not approved yet
- Dom to review; Steve to re-review
- Promoted variable dimensions handling
- Courtney to add some more testing/error handling while we review other PRs
Standard Names
- Add water variables #69
- Michael K to finish review soon
- CGD SE to review if time
- Dom updated branch protection rules so in the future code owners will be added as reviewers
Discussion
Development cycle
- CGD folks prefer develop/main branch (no forking)
- Jesse - concern with main right now is that we have to wait for full host model (right now just UFS) testing before merging to main
- Still want that hurdle for main, but want a faster option as well
- Options:
- Just main branch: would require speeding up and/or automating testing
- Forks: could diverge very easily/quickly
- Framework is a single system; it’s important that it doesn’t diverge
- Development and main branch: code can go into dev branch quickly; dev merged into main at some cadence (TBD)
- Dustin - agrees with development branch
- Agrees that framework structure shouldn’t mirror physics
- As long as development gets into main, he’s ok
- Michael K - almost all problems can be covered by unit testing done in development branch
- Michael K - tags?
- Jesse - tag discussion is a little separate; from our end, a big release of main would be tagged and develop would be tagged when necessary (not enforced on others)
- SIMA will always point to a tag, not the head of a branch
- Cheryl - fix or new feature; when CAM-SIMA wants to grab the framework, that’s when we would tag
- Cheryl proposes incrementing tag #
- Can decide if we want “SIMA-#” or “CCPP_Framework_#” or whatever
- Michael W - would prefer to keep as host model-agnostic as possible
- Michael K - could be date?
- Courtney - can separate “dev” tags and keep alphabetically below release tags
- Dom - could do year and month (and day)
- Then have prefix (or suffix) for ‘release’ and ‘dev’ or whatever
- YYYY-MM-DD-rel and YYYY-MM-DD-dev
- Dom - proposes main tags also become github releases?
- Jesse - tag discussion is a little separate; from our end, a big release of main would be tagged and develop would be tagged when necessary (not enforced on others)
- Michael K - cadence of merges from development to main?
- Could be weekly (bi-weekly if that makes more sense)
- UFS points to top of main, so will need PRs from development to main
- Jesse - only time SIMA will point to development tag will be a temporary hot fix/feature; but will then change to main
- Will need tag from main for CESM releases
- Jesse - once every few weeks sounds good, but SIMA can handle whatever
- Dustin - how do we keep UFS up to date with head of main?
- Can’t test the host on main
- Test would happen on host side when we update the hash
- Michael K - whenever we put a commit in main branch, we have a corresponding PR to the weather model to update the hash
- Agreement to always use head of main branch? All host models.
- Instances when one host model doesn’t want to accept an update? Lots of work?
- Jesse - we will also have a testing system that will be tested on every PR to main
- Will have to modify SIMA sometimes to work with non-backwards-compatible, breaking changes
- Cheryl - will probably run all of our local regression tests on all tags brought into SIMA as well
- Michael K - timeline?
- Jesse - vote we clear out main branch PRs and then open development branch
- Dom - how do we let others know we wish to tag?
- Cheryl - whoever hits the merge button can make the decision
- If there are more than one per day, can add “a”, “b”, “c”
- Courtney - could add to PR that tag will be made after this PR
- Michael K to add to PR template
- Cheryl - whoever hits the merge button can make the decision
- Jesse - do we need to write down the workflow somewhere?
- Michael K - we do have a wiki page that’s out of date; has been meaning to update
- Dom - agreed. Need way to describe procedures (wiki, readme, whatever)
- Michael K - manage_externals change?
- Cheryl - we’re moving to git fleximod in the next couple weeks
- Meeting next week to re-discuss meeting time decision