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 vendors 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 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 guarantee a safe upgrade path for everybody
- For these reasons, we will fix on the stable branch the following kind 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 Development Branch Policy
- The development branch (i.e. SVN trunk) is where all the "interesting" things happens; 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 SVN trunk
- A release candidate (RC) is created off this new branch
- The RC branch enters in a "feature freeze" mode (no new features added)
- Testing and bug fixing continue 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 polishing the RC branch before focusing again on the development branch.
- No official releases are composed from 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 local dev. team