Skip to content

Code Management

Ali.Abdolali edited this page Jun 27, 2019 · 24 revisions

This wiki page describes the code management of this repository.

Checklist for a Code Manager of a Pull Request to develop

The pull request process is documented in this section of our Developer's Guide.

  • Make sure your develop is up to date with the authoritative repository.
  • A pull request will be accepted first to a branch of the NCEP repository, and only reintegrated to the develop branch after passing all tests, unless it has been made by a trusted repository that has followed the regression testing standards fully (make sure to communicate with the developer that the pull request has not gone straight to the develop branch if the case),
    • Regression testing: The full matrix with same y/n options as regtest/bin/matrix_ncep should be completed.
    • Comparing output of Regression Tests: matrix.comp should be used to compare results with the current develop branch.
    • Add the summary output of matrix.comp to the pull request back to the authoritative repository.
    • State which compiler you used to run the regression tests in the PR.
  • 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