-
Notifications
You must be signed in to change notification settings - Fork 55
Project Charter
- The NOAA Environmental Modeling Center (EMC)
- The UCAR Joint Center for Satellite Data Assimilation (JCSDA)
- The Earth Prediction Innovation Center (EPIC)
- The U.S. Naval Research Laboratory (NRL)
- The NASA Global Modeling and Assimilation Office, (GMAO)
Each stakeholder will designate a small number of developers to assist in spack-stack development by becoming a code manager of the spack-stack repo.
| Organization | Code Manager(s) |
|---|---|
| NOAA EMC | Alex Richert, Hang Lei |
| JCSDA | Ashley Griffin, Evan Parker |
| EPIC | Rick Grubin, Ratko Vasic |
| NRL | Dom Heinzeller, TBD |
| NASA | Matthew Thompson, TBD |
The spack-stack project will follow the processes outlined in this document to allow all stakeholders to get the benefits they need from spack-stack.
New packages must be requested as a GitHub issue. There is a template with relevant questions that must be answered.
New packages must have a working package configuration file in spack. If not present, it must be added - if present, it must be examined and tested for correctness. It must be maintained with each new release of the package. Some package files are quite simple, others are very complex and take more work.
Developing and maintaining the spack package file for each package is the responsibility of the organization that has requested that package. In the case of packages used by all organizations (like netcdf-c), the work of maintaining the spack package file is shared.
Spack-stack uses forks of the authoritative spack and spack-packages repositories. Spack core and spack package files should be pushed to the spack main repository, not held within the spack-stack project. For quick development and execution, package files can be temporarily housed in the the spack fork used by spack-stack, but all should be moved to the main spack repositories as time permits.
Regular updates of our spack and spack-packages submodules are necessary to keep the code in sync and simplify the process of sending updates in our fork to upstream.
Each stakeholder will designate developers to install spack-stack on their respective tier-1 platforms and to support users from their organizations.
Any stakeholder can perform a release at any time.
The release process:
- Create a GitHub issue using the release task list template.
- Unless it is a patch release (increasing the z in x.y.z), create a project board for the release at https://github.com/JCSDA/spack-stack/projects.
- Designate any issues that must be fixed before release by assigning it to the epic and the project board, and ensure their completion.
- Install the release tags (or the final version of the release branches to allow for last-minute site config updates) on all supported platforms.
- Update the documentation and create release tags for the spack-stack repo and the spack and spack-packages submodules.
- Update the GitHub Release Notes.
- Perform the release on GitHub.
Sometimes tags are preferrable to releases. Tags can be added at any time. Tag process:
- Add a new issue documenting the reason for the tag.
- Tag the spack-stack repo.
Updates to spack-stack must be requested using the correct issue template in the spack-stack repository. When requesting new packages or new versions of packages, the requestor must provide the necessary information on timeline, build configuration, etc.
Spack-stack environments are complex and shared between users of several organizations and applications. Updates to official releases are therefore limited to exceptional cases. Users are encouraged to request test installations at first, and pending successful evaluation, an update or addition of the package/feature in the next spack-stack release.
Test installations can be requested via issues in the spack-stack repository, and can be more frequent than official updates. Test installations are limited to one platform at a time (depending on the developer’s needs). The installers for that platform are responsible for the deployment. Test installations are made outside the official spack-stack release environment, never in the official environments.
Official updates should be limited in frequency and are only allowed after full acceptance testing (see test installations above). Updates that generate module duplicates require a completely new spack-stack installation and are not permitted for existing releases.
Official updates need to be made consistently across all platforms. There shall never be a situation when an official spack-stack installation on one platform differs from the others in their packages, package configurations, or otherwise (unless required by and encoded in spack-stack itself).
Since official updates require coordination across all platforms, the timeline for these installs must be more generous than for test installs.
Regular, full releases of spack-stack are made every three to six months.
spack-stack developers are committed to maintaining a rolling stock of the last four releases. Under special circumstances (e.g. operational implementations that require long-term support, long-running official retrospectives), selected releases may be kept longer. Maintenance in this context refers to addressing bugs or recompiling in the event of an intrusive update to the system. Adding new functionality or new packages is in general limited to the current and future releases. Modifications to past releases that do not impact existing installations, such as the addition of chained environments/custom Spack repositories, or new templates or site configurations, may be considered on a case-by-case basis.
Developers in need of a long-term installation for their personal experiments are required to install spack-stack themselves - the spack-stack developers are available for support during the original installation. spack-stack developers cannot assist with updating old spack-stack installations from individuals in case they stop working (e.g. due to HPC OS/compiler updates).