Conversation
docs/roadmap.md
Outdated
| @@ -0,0 +1,51 @@ | |||
| # Roadmap for EESSI | |||
|
|
|||
| *(approved by EESSI steering committee: dd-mm-yyyy; valid until: dd-mm-yyyy; to be revised by: dd-mm-yyyy; questions/suggestions: contact-sc@eessi.io)* | |||
There was a problem hiding this comment.
This should be fixed before merging.
Can we just use support@eessi.io here?
docs/roadmap.md
Outdated
|
|
||
| *(approved by EESSI steering committee: dd-mm-yyyy; valid until: dd-mm-yyyy; to be revised by: dd-mm-yyyy; questions/suggestions: contact-sc@eessi.io)* | ||
|
|
||
| The purpose of this roadmap is to focus our collective efforts on the specific goals we aim to achieve together this year. |
There was a problem hiding this comment.
| The purpose of this roadmap is to focus our collective efforts on the specific goals we aim to achieve together this year. | |
| 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. |
docs/roadmap.md
Outdated
|
|
||
| ## Core Infrastructure, Operations & Policy | ||
| ### Lifecycle & Governance Policies | ||
| - Generation Lifecycle: Define clear policies for "Active" vs. "Archived" generations (e.g., how long to add software to EESSI/2023.06) |
There was a problem hiding this comment.
If we use "generation" here, we should clarify somewhere (not here) what we mean.
Up until now we've commonly used "version", we should stick to that here?
docs/roadmap.md
Outdated
| - Bot Modernisation: Upgrade infrastructure; implement tarball analysis to simplify ingestion and track differences | ||
| - Maintainer Support: Leverage the EESSI bot to assist EasyBuild maintainers | ||
| ### Quality Assurance & Compliance | ||
| - Automated License Checks: Towards automatic mandatory license checks for EESSI/2026.06 |
There was a problem hiding this comment.
| - Automated License Checks: Towards automatic mandatory license checks for EESSI/2026.06 | |
| Automated License Checks: Towards automatic mandatory license checks for next EESSI version (2026.x) |
docs/roadmap.md
Outdated
| - Monitoring: Establish regular use of regression tests & status dashboard | ||
| - Performance: Assess performance of end-user applications | ||
| ### Compatibility Layer | ||
| - Release EESSI/2026.06: next generation bundled with upcoming toolchains (update of Gentoo Prefix) |
There was a problem hiding this comment.
| - Release EESSI/2026.06: next generation bundled with upcoming toolchains (update of Gentoo Prefix) | |
| - Release next EESSI version (2026.x): next generation bundled with upcoming toolchains (update of Gentoo Prefix) |
Ideally we avoid use of "generation", since it's not clearly defined
docs/roadmap.md
Outdated
| ### Software Portfolio | ||
| - AI/ML Focus: Extend GPU software (PyTorch, TensorFlow, AlphaFold) | ||
| - Volume Goal: Reach 1,000 unique software packages | ||
| - Toolchains: Integration of lfoss/2025b (EESSI/2025.06) and foss/2026* (EESSI/2026.06) |
There was a problem hiding this comment.
| - Toolchains: Integration of lfoss/2025b (EESSI/2025.06) and foss/2026* (EESSI/2026.06) | |
| - Toolchains: Integration of `lfoss/2025b` (in EESSI 2025.06) and `foss/2026*` (in EESSI 2026.x) toolchains |
| - Toolchains: Integration of lfoss/2025b (EESSI/2025.06) and foss/2026* (EESSI/2026.06) | ||
| ## User Experience & Integration | ||
| ### Direct User Interaction | ||
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide an interface beyondmodules |
There was a problem hiding this comment.
add pointer to https://github.com/EESSI/eessi-cli repo?
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.
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:
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide an interface beyondmodules | |
| - - CLI: Prototype an [EESSI Command Line Interface (CLI)](https://github.com/EESSI/eessi-cli) to provide an interface beyond modules |
Do note the missing space between last two words as well :)
| ## User Experience & Integration | ||
| ### Direct User Interaction | ||
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide an interface beyondmodules | ||
| - Discovery: Create a dynamic software overview |
There was a problem hiding this comment.
add pointer to https://www.eessi.io/docs/available_software/overview/ ?
There was a problem hiding this comment.
i wouldn't do that. the roadmap doesn't need links
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)
There was a problem hiding this comment.
I would say:
- no easy way to filter based on software name or other aspects (like EESSI version);
- poor formatting (too wide table with lots of
x's); - current overview only covers EESSI 2023.06, not 2025.06;
- also include GPU installations;
There was a problem hiding this comment.
"more user-friendly, complete, and informative overview" is perhaps a better term than "dynamic"
| - Discovery: Create a dynamic software overview | ||
| ### Feedback & Transparency | ||
| - Software Wishlist: Implement mechanism (e.g., anonymous forms) for users to request software and trigger documentation PRs | ||
| - Work-in-Progress (WIP) View: Create dashboard/overview of WIP PRs, so users can see upcoming software |
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)
There was a problem hiding this comment.
This sounds cumbersome, why would people use that DOI? If it is automated that's ok.
There was a problem hiding this comment.
For dashboard/overview: is list of open PRs in EESSI/support-layer not enough?
This seems low priority, unless we have a nice way of having an overview of software requests.
| ### Governance & Future | ||
| - Sustainability: Advance steps towards joining Linux Foundation (LF) & HPSF | ||
| ### Community Engagement | ||
| - Events: Continue "Happy Hours", hackathons (focus on documentation/cleanup), and training |
There was a problem hiding this comment.
| - Events: Continue "Happy Hours", hackathons (focus on documentation/cleanup), and training | |
| - Events: Continue "Happy Hours", hackathons (focus on documentation/cleanup), training (webinars, tutorials), and dissemination (talks, blog posts) |
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
docs/roadmap.md
Outdated
| - Sustainability: Advance steps towards joining Linux Foundation (LF) & HPSF | ||
| ### Community Engagement | ||
| - Events: Continue "Happy Hours", hackathons (focus on documentation/cleanup), and training | ||
| - Feedback: Conduct an annual User Survey (aligned with annual EasyBuild survey) |
There was a problem hiding this comment.
I wouldn't aim to align it with annual EasyBuild user survey, it's already tricky to get that out in time (usually Dec/Jan, but not this year yet).
I would more aim for May, so we can report on results in ISC BoF session (fingers crossed there), and use it as input to revise roadmap right before or after summer break.
There was a problem hiding this comment.
I think it was your idea, but maybe I'm wrong.
There was a problem hiding this comment.
I think I said "aligning" but in the sense of not overlapping it with EasyBuild User Survey (partially since people may be reluctant to fill out both surveys in same period)
docs/roadmap.md
Outdated
| @@ -0,0 +1,51 @@ | |||
| # Roadmap for EESSI | |||
There was a problem hiding this comment.
Maybe this should say "Short-term roadmap for EESSI"?
| - Contact info: contact.md | ||
| - Training & events: training-events/index.md | ||
| - Systems where EESSI is available: systems.md | ||
| - Roadmap: roadmap.md |
There was a problem hiding this comment.
| - Roadmap: roadmap.md | |
| - Roadmap (short-term): roadmap/short-term.md |
| - 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 |
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
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide an interface beyondmodules | |
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide a user-friendly interface for EESSI |
There was a problem hiding this comment.
W.r.t. the modules aspect: imagine a tool that supports queries like eessi search gmx (which would list results like GROMACS modules), or eessi search libpng.h
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
| - 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) |
There was a problem hiding this comment.
Is the goal on the roadmap to define the policies, or to also actually implement them?
There was a problem hiding this comment.
define policies implies following them imho
| - 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 |
There was a problem hiding this comment.
| - Diversify Build Sites: Enhance reliability by spreading build operations | |
| - Diversify Build Sites: Enhance reliability by spreading build operations. Simultaneously improve validation on supported CPU flags to maintain consistency. |
There was a problem hiding this comment.
Makes sense, but seems like a separate item to me
| - Cadence: Formalise the yearly release cycle (targeting pre-summer releases) | ||
| ### Build System Modernisation | ||
| - Diversify Build Sites: Enhance reliability by spreading build operations | ||
| - Bot Modernisation: Upgrade infrastructure; implement tarball analysis to simplify ingestion and track differences |
There was a problem hiding this comment.
| - Bot Modernisation: Upgrade infrastructure; implement tarball analysis to simplify ingestion and track differences | |
| - Bot Modernisation: Upgrade infrastructure; implement tarball analysis to facilitate evaluating builds with large numbers of tarballs |
| ### 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 | ||
| - Performance: Assess performance of end-user applications |
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?)
There was a problem hiding this comment.
I think this is about evaluating whether we see performance improvements for zen4 installations on a Zen4 system (vs zen3, zen2, etc.), and perhaps also getting feedback from the software developers whether the performance we're seeing makes sense
There was a problem hiding this comment.
Could result in warnings being printed when particular (old) modules are loaded on recent CPUs
| ## User Experience & Integration | ||
| ### Direct User Interaction | ||
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide an interface beyondmodules | ||
| - Discovery: Create a dynamic software overview |
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)
| - CLI: Prototype an EESSI Command Line Interface (CLI) to provide an interface beyondmodules | ||
| - Discovery: Create a dynamic software overview | ||
| ### Feedback & Transparency | ||
| - Software Wishlist: Implement mechanism (e.g., anonymous forms) for users to request software and trigger documentation PRs |
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?
There was a problem hiding this comment.
An easy way to implement this would be to open issue in EESSI/software-layer repo, along with a bunch of labels to clarifiy context (like EuroHPC), priority, etc.
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 | ||
| ### Workflow Integration | ||
| - Tools: Prototype Nextflow & Spack integration | ||
| - CI/CD: Promote EESSI usage in CI/CD pipelines |
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.
There was a problem hiding this comment.
Blog posts, demos in talks, etc.
| ### Workflow Integration | ||
| - Tools: Prototype Nextflow & Spack integration | ||
| - CI/CD: Promote EESSI usage in CI/CD pipelines | ||
| - Scientific Compliance: Enhance FAIRness of software installations |
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 Engagement | ||
| - Events: Continue "Happy Hours", hackathons (focus on documentation/cleanup), and training | ||
| - Feedback: Conduct an annual User Survey | ||
| - Adoption: Track and map systems/sites that have adopted EESSI |
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.
| ### Build System Modernisation | ||
| - Diversify Build Sites: Enhance reliability by spreading build operations | ||
| - Bot Modernisation: Upgrade infrastructure; implement tarball analysis to simplify ingestion and track differences | ||
| - Maintainer Support: Leverage the EESSI bot to assist EasyBuild maintainers |
There was a problem hiding this comment.
should be rephrased to make clear how this helps EESSI
two different things:
- adopt bot in context of EasyBuild contributions;
- testing EasyBuild contributions on top of EESSI;
| - Maintainer Support: Leverage the EESSI bot to assist EasyBuild maintainers | ||
| ### 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 |
There was a problem hiding this comment.
What does "use" mean here?
Having automated checks that identify performance regressions and report them?
| - Monitoring: Establish regular use of regression tests & status dashboard | ||
| - Performance: Assess performance of end-user applications | ||
| ### Compatibility Layer | ||
| - Release the next EESSI version (2026.x): next version bundled with upcoming toolchains (update of Gentoo Prefix) |
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)
| - Release the next EESSI version (2026.x): next version bundled with upcoming toolchains (update of Gentoo Prefix) | ||
| ## Software Stack & Hardware Targets | ||
| ### Hardware Enablement | ||
| - NVIDIA: Support for Blackwell GPUs |
There was a problem hiding this comment.
should maybe (also) say CC10 + CC12?
| - Feedback: Conduct an annual User Survey | ||
| - Adoption: Track and map systems/sites that have adopted EESSI | ||
| ### Dissemination & Marketing | ||
| - Content: Maintain a standard slide deck, elevator pitch, monthly blog/social updates |
There was a problem hiding this comment.
Maybe also press kit?
"standard slide deck" could be link to recent read-only Google slide decks?
5 participants
Roadmap for EESSI based on wishlist discussion (Happy Hour 22.12.2025), draft presentations/discussions (Happy Hour, 12.1.2026 & EESSI bi-monthly update meeting 15.1.2026) as well as feedback collected so far.
Note, contact email address is just made up.