Project Proposal

1. Name of Project

Spack

2. Project Description

Spack is a combinatorial package manager for supercomputers, desktops, and other computing platforms. It makes installing scientific software easy. Spack isn’t tied to a particular language; it supports multiple languages both interpreted (Python, R, Perl) and compiled (C, C++, Fortran, Rust, Go). It allows users to easily swap compilers and to target specific CPU and GPU microarchitectures.

Spack is both a tool for managing software and a library of over 8,200 package recipes. It has a steady stream of contributions to both.

3. Statement on Alignment with High Performance Software Foundation's Mission

Spack is the most widely used package manager in the High Performance Computing community. It is already a community-driven project, and its users and developers span laboratories, companies, HPC centers, cloud providers, and other parts of industry around the world. Individual users use Spack to enable scientific computing on their personal computers at the smallest scale; large software companies use Spack to enable features for their users; University and government research clusters use Spack to deploy software to their own diverse user communities.

Spack simplifies the task of building software on diverse hardware, which is in line with HPSF's mission to create a portable software stack for HPC. It simplifies and reduces the effort of distributing software for multiple GPUs, and it supports the many specific options and version configurations that pervade the HPC software ecosystem.

The Spack project is committed to supporting all parts of the HPC ecosystem: scientist and analyst end-users, developers, user support staff, and system administrators who manage large facility software deployments.

4. Project Website (please provide a link)

5. Code of Conduct (please provide a link)

Code of Conduct

6. Governance Practices (please provide a link)

Project Governance

7. Sponsors from the High Performance Software Foundation's Technical Advisory Committee

Damien Lebrun-Grandie (@dalg24)
Jim Willenbring (@jwillenbring)

8. What is the project's solution for source control?

Github

9. What is the project's solution for issue tracking?

Github issues

10. Please list all external dependencies and their license

Spack bootstraps the following external software for itself, rom source and/or prebuilt binaries. We require that dependencies like these be permissively licensed.

Required dependencies:
- Clingo (MIT)
Developer dependencies:
- pytest (MIT)
- black (MIT)
- mypy (MIT and PSF 2.0)
- flake8 (MIT)

Spack vendors the below external software in its source repo. We require that any vendored software be permissively licensed and compatible with our Apache-2.0 OR MIT license. Indented packages are only used indirectly.

archspec (MIT or Apache-2.0, spun out of Spack to github.com/archspec)
jsonschema (MIT)
- py-attrs (MIT)
- pyrsistent (MIT)
- six (MIT)
distro (Apache-2.0)
jinja2 (BSD)
- markupsafe (BSD-3-clause)
macholib (MIT)
- altgraph (MIT)
ruamel (MIT)

Spack uses but does not distribute (as part of Spack itself) the following external software. Most of these are widely available and are already preinstalled. We could bootstrap most of these instead of relying on the system, but we do not currently.

Python (Licensed under the PSF License)
C, C++, or Fortran compilers (various licenses including GPL3 and proprietary)
patch (GPL-3.0-or-later)
tar (GPL-3.0-or-later)
gzip (GPL-3.0-or-later)
unzip (BSD-like, permissive)
bzip2 (BSD-like, permissive)
xz (GPL-2.0-or-later AND Public-Domain AND LGPL-2.1-or-later)
zstd (BSD-3-Clause OR GPL-2.0-or-later)
file (BSD-2-clause)
lsb-release (MIT)
gnupg2 (GPL-3.0-or-later)
git (GPL-2.0)
subversion (Apache-2.0)
mercurial (GPL-2.0-or-later)

11. Please describe your release methodology and mechanics

Spack has two major releases per year: before the ACM/IEEE Supercomputing (SC) Conference (usually in November) and before the ISC High Performance (ISC-HPC) conference (usually in May or June). Minor releases are done on an ad-hoc basis according to the severity of bugs found since the last major release. The TSC (see below) has a standing agenda item to consider monthly whether a minor release is warranted.

The technical process for cutting a Spack release is outlined in the Spack Developer Guide. Only TSC members can have sufficient permissions to cut a Spack release (most do not).

12. Please list the project's leadership team

The leadership team for Spack is the Technical Steering Committee (TSC).

Todd Gamblin (@tgamblin), LLNL (TSC Chair)
Greg Becker (@becker33), LLNL
Peter Scheibel (@scheibelp), LLNL
Tamara Dahlgren (@tldahlgren), LLNL
Massimiliano Culpo (@alalazo), np-complete, S.r.l
Harmen Stoppels (@haampie), Stoppels Consulting
Phil Sakievich (@psakievich), SNL
Adam Stewart (@adamjstewart), TU Munich
Wouter Deconinck (@wdconinc), U. Manitoba
John Parent (@johnwparent), Kitware
Ryan Krattiger (@kwryankrattiger), Kitware
Luke Peyralans (@eugeneswalker), U. Oregon
Marc Paterno (@marcpaterno), Fermilab
Mark Krentel (@mwkrentel), Rice University

13. Please describe Software Quality efforts (CI, security, auditing)

Spack uses GitHub Actions for unit testing and ensuring that its core functionality works across python versions and OS's.
Spack has a large-scale CI system maintained by Kitware and U. Oregon. This comprises:
- An EKS cluster running in AWS (status here), hosting:
  - A High-Availability GitLab deployment, gitlab.spack.io
  - Various monitoring services such as Prometheus, Metabase, Clash, and Grafana (see https://spack.io/services/)
  - An instance of Karpenter that allows us to farm builds out to spot instances based on specific microarchitecture compatibility requests.
- Code for EKS deployment is available in the spack/spack-infrastructure repository
- Public and private build caches (see cache.spack.io
- VM Runners in AWS (autoscaling through Karpenter)
- CPU and GPU runners on the U. Oregon Frank cluster
- Spackbot bot to interact with CI from PRs
We post nightly updates to Repology, where you can compare Spack to other software distributions
We host source and binary mirrors of packages in Spack in S3 with CloudFront for worldwide distribution.
Binary signing practices are documented
- We use ephemeral keys to sign and have one locked-down repetitional key.
- PR binaries are not signed with the same keys as public Spack binaries.
- Only binaries that come from 100% reviewed package recipes are built, signed, and hosted in authoritative locations.
We use GitHub's private security reporting, and we commit to fast fixes for security issues with the most recent two major releases.
We regularly deprecate package versions in Spack that are known to have CVEs.

Future plans:

We are working to automate the checking of checksums on artifacts added to Spack packages.
We are working towards more automatic association between Spack packages and CVE-related identifiers like NVD package names.
We have started a collaboration with OpenSSF around SLSA level-3 certification for our build farm.

14. Please list the project members with access to commit to the mainline of the project

There are 39 members of the merge-to-develop team in the Spack Github organization.

15. Please describe the project's decision-making process

We aim for consensus-driven decision making, and we will resort to votes of the TSC when we are unable to reach consensus.

Reviews of pull requests must be approved and merged by a member of merge-to-develop, but these reviews are informed by members of the maintainers team., which has over 500 members. Members of maintainers are experts who have signed up to review specific packages, and their reviews are automatically requested for packages to which they have added their GitHub handle.

16. What is the maturity level of your project?

We aim to join HPSF as a Core stage project. Spack has over 1,400 contributors spread across hundreds of organizations. The Spack TSC has 14 members representing 10 institutions. While we always aim to improve our processes, we have mature processes for continuous integration and release management.

17. Please list the project's official communication channels

Official communication channels are:

Weekly public meetings
Monthly public Technical Steering Committee meetings
Github issues, PRs, and discussions
Spack slack instance (slack.spack.io)
An announcements-only mailing list (currently on Google Groups)

18. Please list the project's social media accounts

X (Twitter): @spackpm Mastodon: @spack@mast.hpc.social

19. Please describe any existing financial sponsorships

Contributors are primarily paid by their own institution to work on Spack, though many also use their free time to contribute to Spack.

Most of Spack's funding comes from NNSA's ASC program, which supports mission-critical capabilities at NNSA labs and is not expected to end. ASC funds developers at LLNL, SNL, Kitware, and smaller independent consultants.
Spack has additional funding from the DOE/SC Software Sustainability PESO project (2023-2028) and from LLNL's own internal overhead funding sources.
There are significant efforts to contribute to Spack at Fermilab, CERN, Japan's RIKEN R-CCS, University of Oregon, and others.

Spack also receives in-kind donations of compute cycles (cloud and on-prem) from Amazon Web Services and the University of Oregon for compute cycles that enable the high level of continuous integration on the project today.

20. Please describe the project's infrastructure needs or requests

Spack is interested in HPSF support in organizing an annual user meeting. Spack is also seeking support from HPSF in financing enterprise support for Spack slack to preserve the history of our default communication channel.

Spack is also interested in exploring how its CI system can be expanded to support more HPSF projects, as part of the HPSF CI Working Group.

Criteria for Sandbox Stage

[ ] Meet all requirements to be a Linux Foundation project
- Evidence: LLNL signed Spack paperwork and became an LF project.
[ ] Have 2 TAC sponsors to champion the project & provide mentorship as needed
- Evidence: @dalg24, @jwillenbring
[ ] Submit a proposal for membership and present it at a meeting of the TAC
- Evidence: This proposal
[ ] Have a charter document with an intellectual property policy that leverages open licenses, including, in the case of contributions of code, the use of one or more licenses approved as “open” by the Open Source Initiative. The staff of the High Performance Software Foundation can assist projects in preparing a technical charter following the High Performance Software Foundation’s standard template.
- Evidence: https://github.com/spack/governance/blob/main/CHARTER.md
[ ] Have a code of conduct
- Evidence: https://github.com/spack/governance/blob/main/CODE_OF_CONDUCT.md

Criteria for Established Stage

To be considered for Established Stage, the project must meet the Sandbox requirements as well as the following:

[ ] Document that it is being used successfully in production by at least three independent end users which, in the TAC’s judgment, are of adequate quality and scope.
- Evidence: See above; Spack is used by and has contributors from hundreds of organizations including all national labs, the big 3 cloud providers, universities, and other companies.
[ ] Demonstrate development processes (e.g., use of pull requests, code review, testing, CI) that lower barriers to contribution and ensure software quality necessary for increased adoption.
- Evidence: See evidence of development processes above and in TAC presentation.
[ ] Demonstrate a substantial ongoing flow of commits and merged contributions.
- Evidence: See https://github.com/spack/spack/pulse/monthly

Criteria for Core Stage

[ ] Have a defined governing body of at least 4 or more members (owners and core maintainers), of which no more than 1/2 of whom are affiliated with the same employer. No single institution may control a voting majority of the governing body.
[ ] Have a documented and publicly accessible description of the project's governance, decision-making, and release processes.
- Evidence: See https://github.com/spack/governance/blob/main/GOVERNANCE.md
[ ] Have a healthy number of committers from at least two organizations. A committer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project.
- Evidence: See committer organization chart below.
[ ] Explicitly defined security reporting and incident mitigation processes, as appropriate to the security risks of the project
- See https://github.com/spack/spack/security/policy (we use GitHub Security reporting)
[ ] Explicitly defined project governance and committer process.
[ ] Provide evidence of widespread adoption in the HPC ecosystem or in some important component thereof.
- Evidence: see committer chart below.

Supporting Material

Lines of code in Spack Packages by Organization

Lines of code in Spack core by organization

hpsfoundation / tac