• Home
• Capabilities
• Documentation
• Getting Started
• Running NEMS
• Launcher
• NEMSIO
• GFS Post
• Output
• Testbed
• Miscellany

Functionally Equivalent Environment (FEE) -> EMC & DTC

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

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