Skip Navigation Links
NOAA logo - Click to go to the NOAA homepage National Weather Service NWS logo - Click to go to the NWS homepage
EMC Logo
Navigation Bar Left Cap Home News Organization
Navigation Bar End Cap

         MISSION / VISION    |    About EMC

NOAA Environmental Modeling System


This page is for any content related to the NCEP/DTC testbed collaboration.

Click to enlarge

Functionally Equivalent Environment (FEE) -> EMC & DTC

O2R TESTBED's Functional Equivalence Requirements

TESTBED R2O "products"

Components of the Testbed FSE/FEE:

  1. Architecture: Hardware, Registries, Cache, Processors, Memory management, OS, Data storage and management, Support
  2. Resources: PEs, Memory, Cycles, Queues etc.
  3. Environment: OS version, SYS Libraries, Compilers/Versions, Flexible module environment, 3rd party libraries, Flex Env variables mechanism
  4. Built system: Scripting, Workflows, Launchers, Parallel submission
  5. Data: Availability, Formats, Compatibility, Precision
  6. Code: Documentation, Self-documenting, Auto configuration, Testing/evaluation and benchmark system

Porting :: FSE/FEE :: Availability

Cross SVN -- Control, Release and Management Policies (DRAFT)

NCAR and EMC repositories

  • Due to the difficulties of SVN conflict resolutions, any site developers are the decision makers on the site-related repository.
  • Other party of corresponding repository is considered as a "3rd party vendor S/W" and collected on the "vendor branch" via "SVN import".
  • Each site-team manages a "development trunk", "stable" and "vendor branches".
  • Difference in the versions and patches are articulated, documented, and announced.
  • Import is available from the stable branch only.
  • Site team generally is not allowed to commit on the "3rd party vendor development trunk".

Branching and Release Management Policy

  • There are usually two active branches at any given time:
    • The stable branch
    • The development branch
  • Release packages from stable and development branches are linked to one doc.
  • Between releases, the latest code is always available from our Subversion repository.

Stable branch policy

  • The stable branch should receive only the most important bug fixes, so that:
    • The development resources are focused on development branch, avoiding porting efforts when possible.
    • The stable branch is kept very stable and hence guarantees a safe upgrade path for everybody.
  • For these reasons, we will fix on the stable branch the following kinds of issues:
    • Bugs with category "security".
    • Critical bugs like deployment stoppers, blank screens, installation and upgrade issues.
    • Bugs that are generating a lot of support requests.

If unsure, feel free to ask on the m dev mailing list about development branch policy.

  • The development branch (i.e. SVN trunk) is where all the "interesting" things happen; new features and bug fixes are usually applied here first, then tested and ported to the stable branch when deemed necessary.

Whenever the development branch reaches a state considered good enough for becoming the "stable" one, the following happens:

  • A new branch is created from the SVN trunk.
  • A release candidate (RC) is created off this new branch.
  • The RC branch enters into a "feature freeze" mode (no new features added).
  • Testing and bug fixing continues on the RC branch until it can be declared stable.
  • During feature freeze:
    • New features can still enter SVN trunk, but all developers are encouraged to help polish the RC branch before focusing again on the development branch.
    • No official releases are composed from the SVN trunk (that is, the soon-to-be development branch).

ONLY CRITICAL FIXES are applied to the stable branch.

At release time:

  • The RC branch becomes the new stable branch.
  • Support ends for the old stable branch.
  • Normal development resumes on SVN trunk by the local development team.

Questions or comments about the testbed? Please contact Eugene Mirvis.