CVM Release Process

Finalizing the Release

Target Dates

New versions of CVM-T will be issued on a quarterly basis, beginning Dec 1, 2010 (10.12.1). This is a nominal schedule in that there will be no new releases if no changes have been made, and releases may be delayed to fix problems or perform additional testing.

Testing

The CVM-H release candidate will be submitted to the Automated Test Framework where it will be evaluated in a number of unit and acceptance tests. The primary acceptance test involves a goodness of fit (GoF) evaluation for the 2008 Chino Hills earthquake. The release candidate passes the testing when the following criteria are met:

• CVM-H and cvm2mesh are successfully built
• All CVM-H unit tests pass
• cvm2mesh is successfully able to extract a Chino Hills 100m mesh
• The SCEC Broadband GoF bias for all periods in the range 1s-10s is less than or equal to the GoF bias computed in the previous release. In other words, the goodness of fit of Chino Hills synthetics versus observed must improve from release to release.

If tests fail or problems are found, they will be corrected and the tests re-run until all tests pass.

Code Freeze

Following successful testing, all CVM-T code bases (cvmh, cvmtest, cvm2mesh, viz-cvm) will be frozen from further changes. This freeze applies to the underlying community velocity model as well. Code freezes must be performed a minimum of three weeks prior to the anticipated release date.

Scientific Review

Scientific review of AWT simulation results and horizontal/profile plots for correctness. A period of one week following a code freeze is allocated to this review activity. The scientific review team is comprised of John Shaw and Andreas Plesch of Harvard University, Geoff Ely of USC, and Kim Olsen of UCSD. The review team makes a recommendation of either to proceed with the release, or hold in order to perform more tests or changes.

Release Authority

The release authority, Phil Maechling, examines the test results and the recommendation of the scientific reviewers and makes the decision whether or not to proceed with the new release. A one week period is allocated for this activity.

Assign Release Tag

A release tag is assigned to the release candidate. Release tags will have the format: YY.MM.RR

where:

• YY: Two digit year
• MM: Two digit month
• RR: Mid-month revision id, starting at 1.

Package Products

The following packages will be posted for download at (TBD):

• cvm-t-system-YY.MM.RR.tgz: Comprehensive package containing CVM-H, cvmtest, cvm2mesh, and viz-cvm.
• cvm-t-cvm-YY.MM.RR.tgz: Package containing CVM-H
• cvm-t-awt-YY.MM.RR.tgz: Package containing cvmtest
• cvm-t-evt-YY.MM.RR.tgz: Package containing cvm2mesh, viz-cvm

User Community Notification

Communication with the user community is accomplished with an email list (cvm-t@usc.edu) with public subscription. Once the product packages have been publicly posted, a notification is sent to this email lists with release notes and information where to get the new version.

Software Defects

Defect Tracking

Trac systems will be established for svn repositories cvmh, cvm2mesh, cvmtest, and viz-cvm. Users, scientists, and developers are all encouraged to open new Trac tickets to report bugs, or request new features.

Defects in a Release Candidate

When a defect is found in a release candidate, it will be tracked with a Trac trouble ticket. The developers (and possibly scientific reviewers) will need to determine the severity of the defect and if it is necessary to delay the upcoming release. Early in the release process there is still time to fix minor bugs and retest the system. Serious defects in either the s/w or the underlying model may require significant time to fix and can cause a release to be postponed.

Defects in an Existing Release

When a defect is found in the most recent existing release, it will be tracked with a Trac trouble ticket. If a defect is found in an older release, but it is not present in the most recent release, the user will be advised to upgrade to the latest version.

A notification will also be sent to the email subscription list announcing that a defect has been found and assigned a Trac ticket number. The developers (and possibly scientific reviewers) will need to determine if a bug fix release is warranted to fix the defect. If the problem is deemed minor, its fix may be rolled into the next quarterly release. If the fix is deemed a priority or directly impacts s/w usability, a bug fix release will be issued that directly addresses the defect. This bug fix release will follow the standard release process except there will be no time requirements for each step of the process in order to get the fix into the hands of users as quickly as possible.