CASA Packaging Requirements

This page describes:

• the types packages the CASA development group must publish,
• what changes each type of package must contain,
• when each type of package must be built, and
• criteria that must be used to decide if a package is good enough to publish.

Status: DRAFT - Requested review by J. Kern and M. Rawings 2013-03-19

Purpose

The purpose of these requirements is to ensure CASA users and developers understand when each type of CASA package must be delivered, what changes it must contain, and how much testing has been performed on that package. These requirements are deliberately minimal to allow flexibility for handling special cases.

Common

• "CASA" refers to all code in casacore, code, gcwrap, and asap, and all data in casa-data.
• As much as possible, all CASA build, data management, and test work must be automated on one continuous integration (CI) server to ensure all CASA developers have full access to all data on the health of CASA code.
• All acceptance tests must pass on all CASA supported OSs.
• Acceptable test failures on Linux distributions or OS X versions other than those on the supported OS list will be determined on a case by case basis.

Package Publishing

TODO: Split this section out into a separate page on package contents.

• OS X packages must be published in a native package format. At this time we publish dmg packages.
• Linux tar packages must be published for
  • 64 bit Redhat Enterprise Linux 5.7
  • 64 bit Linux distributions other than those on the supported list
• All package file names must include enough information to identify the contents of the package to both users and developers:
  • the package type (test, stable, release),
  • a CASA version number,
  • a source code control ID. At this time we use Subversion revision IDs. The package type implicitly identifies the Subversion branch.
  • an identifier for the OS the package is intended for.
    • ISSUE: ASAP Subversion source code control IDs are inconsistent with casacore, code, and gcwrap source code control IDs, making ASAP version reporting difficult.
    • ISSUE: casa-data Subversion source code control IDs are inconsistent with casacore, code, and gcwrap source code control IDs, making casa-data version reporting difficult.
• For each package published, a set of packages built from the same source code must be published for all supported OSs at the same time.

• ISSUE: casa-data post install updates are handled inconsistently on Linux and OS X.
  • CASA provides casa-data-YYYYMMDD-N data rpms.
  • On OS X, CASA automatically updates casa-data on startup.
  • Users of tar packages outside NRAO must update casa-data manually or create their own automated update system.
  • TODO: move this issue to Jira.

Reporting

• Package publication must be reported. Details are TBD.

Test Packages

Audience

Test packages are intended for ALMA and EVLA Astronomers working directly with CASA developers on specific features. Test packages must not be publicised beyond this audience.

Trigger

The CASA release engineer must start on a new test package as early as possible on the first working day of every week. Until complete, this is the release engineer's primary task.

Contents

Test packages must include all changes committed to the casacore, code, gcwrap, and asap repository trunks since the previous test package, except changes marked not ready for test by the developer responsible for the change.

Publishing Criteria

Test packages must pass all test package acceptance tests.

Stable Packages

Audience

Stable packages are intended for ALMA and EVLA Astronomers working with the CASA developers on CASA acceptance testing, or who simple want to preview new features before the next release.

Trigger

The CASA release engineer must start on a new stable package as early as possible on the first working day after the 15th of the month. If this is also the start of a new work week, work on the stable package is defferred until that week's test package is complete. Until complete, this is the release engineer's primary task.

Contents

Stable packages must include all changes included in test packages published since the previous stable package.

Publishing Criteria

Stable packages must pass all test package acceptance tests and all stable package acceptance tests.

Release Packages

Audience

Release packages are intended for all CASA users who do not have a need to track development in progress. Release packages must be available to all CASA users.

Trigger

The CASA release engineer must start on a new release package as early as possible on the first working day after the CASA feature freeze for that release. If this is also the start of a new work week, work on the release package is defferred until that week's test package is complete. Feature freeze dates are typically March 15th and September 15th every year. Since these are also trigger dates for stable packages, work on the release package is defferred until that month's stable package is complete. Until complete, this is the release engineer's primary task.

Contents

Release packages must include all changes included in stable packages published since the previous release package.

Publishing Criteria

Release packages must pass all test package acceptance tests, all stable package acceptance tests, all release package acceptance tests, and all User Testing planned for that release.

Ideas to Consider Later for Additional Criteria

• performace acceptance tests
• test coverage acceptance tests
• code quality acceptance tests
• usability acceptance tests
• ALMA/EVLA pipeline acceptance tests

-- ScottRankin - 2013-03-19