EESSI roadmap 2026 for approval by SC #680
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,52 @@ | ||||||||||
| # Short-term roadmap for EESSI | ||||||||||
|
|
||||||||||
| *(approved by EESSI steering committee: 19-02-2026; valid until: 18-02-2027; to be revised by: 18-12-2026; questions/suggestions: support@eessi.io)* | ||||||||||
|
|
||||||||||
| The purpose of this roadmap is to focus the collective effort of the EESSI | ||||||||||
| community on the specific goals we aim to achieve together in the coming year. | ||||||||||
|
|
||||||||||
| ## Core Infrastructure, Operations & Policy | ||||||||||
| ### Lifecycle & Governance Policies | ||||||||||
| - Version Lifecycle: Define clear policies for "Active" vs. "Archived" versions (e.g., how long to add software to EESSI/2023.06) | ||||||||||
| - Development Policy: Establish lifetime policies for experimental installations on `dev.eessi.io` | ||||||||||
| - Cadence: Formalise the yearly release cycle (targeting pre-summer releases) | ||||||||||
| ### Build System Modernisation | ||||||||||
| - Diversify Build Sites: Enhance reliability by spreading build operations | ||||||||||
|
Collaborator
There was a problem hiding this comment.
Suggested change
Contributor
There was a problem hiding this comment. Makes sense, but seems like a separate item to me |
||||||||||
| - Bot Modernisation: Upgrade infrastructure; implement tarball analysis to simplify ingestion and track differences | ||||||||||
|
Collaborator
There was a problem hiding this comment.
Suggested change
|
||||||||||
| - Maintainer Support: Leverage the EESSI bot to assist EasyBuild maintainers | ||||||||||
|
Contributor
There was a problem hiding this comment. should be rephrased to make clear how this helps EESSI two different things:
|
||||||||||
| ### Quality Assurance & Compliance | ||||||||||
| - Automated License Checks: Towards automatic mandatory license checks for the next EESSI version (2026.x) | ||||||||||
| - Monitoring: Establish regular use of regression tests & status dashboard | ||||||||||
|
Contributor
There was a problem hiding this comment. What does "use" mean here? Having automated checks that identify performance regressions and report them? |
||||||||||
| - Performance: Assess performance of end-user applications | ||||||||||
|
Collaborator
There was a problem hiding this comment. I'm not sure exactly what this means. I'm assuming this goes beyond the scope of the regression testing we do with the EESSI test suite? Or doesn't it? (if it doesn't: how is it different from the previous item?)
Contributor
There was a problem hiding this comment. I think this is about evaluating whether we see performance improvements for
Contributor
There was a problem hiding this comment. Could result in warnings being printed when particular (old) modules are loaded on recent CPUs |
||||||||||
| ### Compatibility Layer | ||||||||||
| - Release the next EESSI version (2026.x): next version bundled with upcoming toolchains (update of Gentoo Prefix) | ||||||||||
|
Contributor
There was a problem hiding this comment. This doesn't require a specific roadmap item, can be a single more high-level item on kickstarting a new EESSI version (according to yearly release cycle) |
||||||||||
| ## Software Stack & Hardware Targets | ||||||||||
| ### Hardware Enablement | ||||||||||
| - NVIDIA: Support for Blackwell GPUs | ||||||||||
|
Contributor
There was a problem hiding this comment. should maybe (also) say CC10 + CC12? |
||||||||||
| - AMD: Support for Zen5 and ROCm stack (AMD GPUs) | ||||||||||
| - ARM: Support for AWS Graviton 4+5 | ||||||||||
| ### Software Portfolio | ||||||||||
| - AI/ML Focus: Extend GPU software (PyTorch, TensorFlow, AlphaFold) | ||||||||||
| - Volume Goal: Reach 1,000 unique software packages | ||||||||||
| - Toolchains: Integration of `lfoss/2025b` (in EESSI 2025.06) and `foss/2026*` (in EESSI 2026.x) toolchains | ||||||||||
| ## User Experience & Integration | ||||||||||
| ### Direct User Interaction | ||||||||||
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide an interface beyondmodules | ||||||||||
|
Contributor
There was a problem hiding this comment. add pointer to https://github.com/EESSI/eessi-cli repo?
Collaborator
Author
There was a problem hiding this comment. i think we don't need a pointer here, and if we start adding a pointer we should do this for other stuff too. then it gets a mess.
Contributor
There was a problem hiding this comment. OK, no strong feelings about that, I just figured it could be helpful to clarify to people. Doesn't have to look messy, could be done like this:
Suggested change
Do note the missing space between last two words as well :)
Collaborator
There was a problem hiding this comment. I'm still fuzzy on what our plan with the CLI is. I was rather sceptical when it was suggested to be an alternative interface for modules, as then it just feels as a glorified wrapper. But then what @boegel demo-ed showed so much more value - facilitating CVMFS config checking, dropping into an EESSI shell. I think we should phrase this more broadly, maybe something like
Suggested change
Contributor
There was a problem hiding this comment. W.r.t. the modules aspect: imagine a tool that supports queries like
Contributor
There was a problem hiding this comment. see also https://hackmd.io/NASotth6R9aoTQTQx9VqLg?view we should make that an overview issue in https://github.com/EESSI/eessi-cli |
||||||||||
| - Discovery: Create a dynamic software overview | ||||||||||
|
Contributor
There was a problem hiding this comment. add pointer to https://www.eessi.io/docs/available_software/overview/ ?
Collaborator
Author
There was a problem hiding this comment. i wouldn't do that. the roadmap doesn't need links
Collaborator
There was a problem hiding this comment. It doesn't, but the current description is in my view to abstract. What does that mean, a 'dynamic software overview'? What's not dynamic about it currently? Maybe a question for @boegel : why was the previous software overview not good enough? The answer to that should be what's here in the roadmap (e.g. restructure to software overview to accomodate the increasing number of CPU/GPU architectures, implement capabilities to search for architecture support - I don't know what)
Contributor
There was a problem hiding this comment. I would say:
Contributor
There was a problem hiding this comment. "more user-friendly, complete, and informative overview" is perhaps a better term than "dynamic" |
||||||||||
| ### Feedback & Transparency | ||||||||||
| - Software Wishlist: Implement mechanism (e.g., anonymous forms) for users to request software and trigger documentation PRs | ||||||||||
|
Collaborator
There was a problem hiding this comment. 'trigger documentation PRs'? How is that related to a software wishlist? Also: they can make PRs already, no?
Contributor
There was a problem hiding this comment. An easy way to implement this would be to open issue in Some kind of voting mechanism on top should be feasible (thumbs up in PR description) |
||||||||||
| - Work-in-Progress (WIP) View: Create dashboard/overview of WIP PRs, so users can see upcoming software | ||||||||||
|
Contributor
There was a problem hiding this comment. We should add the "release" concept here: monthly "releases" (needs better name, maybe "revision") with a changelog (and associated DOI)
Member
There was a problem hiding this comment. This sounds cumbersome, why would people use that DOI? If it is automated that's ok.
Contributor
There was a problem hiding this comment. For dashboard/overview: is list of open PRs in This seems low priority, unless we have a nice way of having an overview of software requests. |
||||||||||
| ### Workflow Integration | ||||||||||
| - Tools: Prototype Nextflow & Spack integration | ||||||||||
| - CI/CD: Promote EESSI usage in CI/CD pipelines | ||||||||||
|
Collaborator
There was a problem hiding this comment. Are we planning concrete activities beyond what we already have? I.e. the GH/Gitlab actions are already there - and have been for a long time.
Contributor
There was a problem hiding this comment. Blog posts, demos in talks, etc. |
||||||||||
| - Scientific Compliance: Enhance FAIRness of software installations | ||||||||||
|
Collaborator
There was a problem hiding this comment. This is very abstract to me. What concrete action are we planning in the next year to enhance this FAIRness? (maybe: bring the metadata API to maturity or something?) |
||||||||||
| ## Community, Outreach & Sustainability | ||||||||||
| ### Governance & Future | ||||||||||
| - Sustainability: Advance steps towards joining Linux Foundation (LF) & HPSF | ||||||||||
| ### Community Engagement | ||||||||||
| - Events: Continue "Happy Hours", hackathons (focus on documentation/cleanup), and training | ||||||||||
|
Contributor
There was a problem hiding this comment.
Suggested change
Contributor
There was a problem hiding this comment. Why "focus on documentation/cleanup"? I think the topic we have in mind for next EESSI hackathon (during EuroHPC User Days 2026) is to focus on process for onboarding software into EESSI |
||||||||||
| - Feedback: Conduct an annual User Survey | ||||||||||
| - Adoption: Track and map systems/sites that have adopted EESSI | ||||||||||
|
Collaborator
There was a problem hiding this comment. Again: are we planning concrete actions on this? Or is it just about maintaining the list in the docs we already have? I don't think the latter is important enough to warrant being mentioned explicitely on the roadmap. |
||||||||||
| ### Dissemination & Marketing | ||||||||||
| - Content: Maintain a standard slide deck, elevator pitch, monthly blog/social updates | ||||||||||
|
Contributor
There was a problem hiding this comment. Maybe also press kit? "standard slide deck" could be link to recent read-only Google slide decks? |
||||||||||
| - Conference: FOSDEM, EuroHPC Summit, ISC, EUM, and EuroHPC User Days, etc | ||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the goal on the roadmap to define the policies, or to also actually implement them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
define policies implies following them imho