forked from ESCOMP/CTSM
/
.CLMTrunkChecklist
58 lines (41 loc) · 2.32 KB
/
.CLMTrunkChecklist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
Checklist of steps to do to make a CLM Trunk Tag Mar/7th/2017
CLM Code Management team.
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 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 -- '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 -- '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) 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.
(4) Merge the PR to master when review is approved
(5) Compare master to branch show that they are identical
git diff master remote/feature-branch
This should show no diffs
(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)
6b -- update date stamp on ChangeLog
./UpDateChangeLog.pl -update
6c -- commit new change files
(7) Make the trunk tag
(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 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.