Skip to content

RDASApp code management policy

Guoqing Ge edited this page Sep 26, 2024 · 15 revisions
  1. Developers are expected to make a personal fork, make changes on the fork, and create PRs to the authoritative repo.
    DO NOT push personal branches to the authoritative repo.

  2. To discuss any RDASApp problems/issues, developers should first make sure they can repeat the problem by starting with a fresh clone. This is because RDASApp uses lots of submodules, it is very easy for those submodules to get unsynced and inconsistent in the working copy, and then people actually discuss different things. A simple sanity check by making a fresh clone may quickly bring different parties on the same page.
        (If you would like to get help syncing submodules on your local working copy, Guoqing.Ge@noaa.gov can help)

  3. Each PR will require at least one approval before a merge. It is preferred that GSL developers' PRs get at least one approval from EMC and EMC developers' PRs get at least one approval from GSL.

  4. For Every PR involving code/script changes, code manager should trigger automatic rrfs-tests on Hera/Jet/Hercules by adding test_hera, test_jet, and test_hercules labels to the given PR.