Code Management

This wiki page describes the code management of this repository.

Checklist for a Code Manager or Reviewer of a Pull Request to develop

• Pull requests should be separate for different features or pull requests. (Ie. branches should be single purpose)
• Look at the code itself to confirm that code is following WW3 standard practices.
• Make sure GOTOs were not added. Particularly, computed GOTOs will not be allowed back into the develop. An example of a computed GOTO is:

 GO TO (901,902,903) L2

In general we will strongly discourage any additional general GOTOs as if you add one, we have to remove another one from somewhere.

• All headers of modules and routines have been updated.
• If a new feature was added, was a new regression test added?
• If w3iogrmd.ftn was updated, make sure to update VERGRD?
• Are required manual updates included?
• Should this be a new version number X.XX?
• Run the full set of the regtests (for example at EMC we use regtests/bin/matrix_ncep to generate the list of tests with information on submitting to queue). To confirm all tests ran without error 'grep -nri error matrix.out' Then, we use matrix.comp (see: How to use matrix.comp to compare regtests with master) to confirm if answers have changed between the current master and the tested branch.

Checklist for a Developer Submitting to develop

When you are ready to create a pull request back to develop, make sure the list below has been completed and then send an email to the code manager with the branch name and answer to the questions below:

• Did you add any GOTOs? Computed GOTOs will not be allowed back into the develop. An example of a computed GOTO is:

 GO TO (901,902,903) L2

but in general, we will strongly discourage any additional general GOTOs as if you add one, we have to remove another one from somewhere.

• All headers of modules and routines have been updated.
• Does a new regtest need to be made? If so have you added it and completed Checklist for Adding or Modifying a Regtest
• If w3iogrmd.ftn was updated, did you update VERGRD?
• Have you made the required manual updates?
• Will this correspond to a new version X.XX? If yes, make a comment in your issue indicating that this including information about that the "about" description in the manual page should be.
• Code managers will run a full set of the regtests (for example at EMC we use regtests/bin/matrix_ncep to generate the list of tests with information on submitting to queue). To confirm all tests ran without error 'grep -nri error matrix.out' then, we use matrix.comp (see: How to use matrix.comp to compare regtests with master) to confirm if answers have changed between the current master and the tested branch.

Checklist for Updating Version Number

The version number update is performed by the authoritative repository code manager. The following is the checklist of tasks when updating the version number.

1. Update Roadmap with version number
2. Update front redmine page
3. Update any subroutine 7.XX (7.xx, 7.XY, X.YZ, etc.) to correct version number
4. Update version number in guide/guide.tex, manual/defs.tex, manual/intro/about.tex
5. Update version number in w3initmd.ftn (WWVER)
6. Commit message (with correct version number) "master: Updated version number to 7.XX"
7. Send email update to ncep.list.wwatch3.discussion-group@lstsrv.ncep.noaa.gov

Checklist for Public Release

The list of tests that will be run before a public release is created is:

Running matrix.base for the following compilers:

• Intel (defaults in comp.Intel)
• Intel with debug compiler options and no optimization ( opt="-c $list -O0 -assume byterecl -g -traceback -check all -fpe0 -ftrapuv -module $path_m")
• Portland (comp.Portland)
• GNU (comp.Gnu)
• Run with S T and other debug flags to make sure tests run

Test NCEP operational systems:

• multi_1
• Great Lakes