NOAA Environmental Modeling System
This page is for any content related to the NCEP/DTC testbed collaboration.
Functionally Equivalent Environment (FEE) -> EMC & DTC
O2R TESTBED's Functional Equivalence Requirements
TESTBED R2O "products"
Components of the Testbed FSE/FEE:
- Architecture: Hardware, Registries, Cache, Processors, Memory management, OS, Data storage and management, Support
- Resources: PEs, Memory, Cycles, Queues etc.
- Environment: OS version, SYS Libraries, Compilers/Versions, Flexible module environment, 3rd party libraries, Flex Env variables mechanism
- Built system: Scripting, Workflows, Launchers, Parallel submission
- Data: Availability, Formats, Compatibility, Precision
- 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.