Skip to content

CCPP Framework Meeting Minutes 2024 05 13

Courtney Peverley edited this page May 13, 2024 · 3 revisions

Agenda


Attendees: Mike Kavulich,

GitHub issues/PRs

CCPP Framework (issues, PRs, discussions)

Standard names (issues, PRs, discussions)

New items for discussion

  • 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

Updates from last time

Previous notes

Other business

Meeting time survey: https://whenisgood.net/r45txw7

Meeting notes

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?
  • 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
  • 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
Clone this wiki locally