From 0f43894ff2f1e3c112a6c0ebf5ca7857251fd8da Mon Sep 17 00:00:00 2001 From: Erik Kluzek Date: Mon, 5 Feb 2018 13:11:19 -0700 Subject: [PATCH] Update tag checklist --- .CLMTrunkChecklist | 51 +++++++++++++++++++++++----------------------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/.CLMTrunkChecklist b/.CLMTrunkChecklist index 8774800891..de48172bb3 100644 --- a/.CLMTrunkChecklist +++ b/.CLMTrunkChecklist @@ -2,58 +2,57 @@ Checklist of steps to do to make a CLM Trunk Tag Mar/7th/2017 CLM Code Management team. -(1) Do all testing on the branch – i.e., on a sandbox that is just a clean checkout of -the branch (save to next tag name) +See the wiki page for this on: + +https://github.com/ESCOMP/ctsm/wiki/CTSM-development-workflow + +(1) Do all testing on your fork/feature-branch 1a -- make sure any new failing tests are either fixed or approved as a new expected fail 1b -- update the ExpectedFails list if expected fails changes in 1a - $EDITOR components/clm/cime_config/testdefs/ExpectedTestFails.xml + $EDITOR cime_config/testdefs/ExpectedTestFails.xml 1c -- make sure you understand any changes to the baselines -- to document in ChangeLog (2) Use diff and status to make sure any new files are in the repo and only the correct changes are on the branch - 2a -- 'svn status' to check that you've added any new files and haven't + 2a -- 'git status' to check that you've added any new files and haven't added any non source files that aren't needed in the repository - 2b -- 'svn diff' to check that your changes are correct and you didn't accidentally + 2b -- 'git diff' to check that your changes are correct and you didn't accidentally add something unintentionally 2c -- you could also update the content of the changelog here on the branch -(3) Tag the branch - -(4) Merge branch tag to trunk and update to get any new externals +(3) Submit a pull request (PR) for the changes + Have someone review it if you are able. At minimum review it youself. The PR mechanism + on git is an excellent way to code review code for both yourself and others. Also make + sure all your changes are correct, changes that shouldn't have gone in don't, and all new + files are added in. -(5) Commit to trunk +(4) Merge the PR to master when review is approved -(6) Compare trunk to branch show that they are identical +(5) Compare master to branch show that they are identical -svn diff --ignore-properties https://svn-ccsm-models.cgd.ucar.edu/clm2/trunk -https://svn-ccsm-models.cgd.ucar.edu/clm2/branches/BRANCHNAME +git diff master remote/feature-branch This should show no diffs -(7) Update ChangeLog - 7a -- if you didn't update the content in 2c do it now +(6) Update ChangeLog + 6a -- if you didn't update the content in 2c do it now (Increment the science minor number if answers change in an important way) - 7b -- update date stamp on ChangeLog + 6b -- update date stamp on ChangeLog ./UpDateChangeLog.pl -update - 7c -- commit new change files + 6c -- commit new change files -(8) Make the trunk tag +(7) Make the trunk tag -(9) Send an email to clm-dev with the contents of the latest ChangeLog +(8) Send an email to clm-dev with the contents of the latest ChangeLog entry (until we have automated this for the git repo) NOTES: -(1) -- Always test on a branch so that we can change tag order if needed. Put baselines -in the next tag name, as we can easily change afterwards if needed. -(2) -- This provides a final self code review of your changes. Having someone else review your -code is also useful, but making sure you review it careful is also important. This step makes -sure you don't commit changes you shouldn't and makes sure you don't neglect to add new files -that need to be added to the repository. It's easy for either of those problems to happen without -doing this step. -(7) or 2c -- Updating the ChangeLog needs to happen on the trunk shortly before the new +(1) -- Always test on your fork with a feature-branch so that we can change tag order if needed. Put +baselines in the next tag name, as we can easily change afterwards if needed. +(6) or 2c -- Updating the ChangeLog needs to happen on the trunk shortly before the new trunk tag is made. There is a cronjob that emails errors when the ChangeLog was updated but the new trunk tag wasn't made.