EasyBuild Maintainers Summit 2026

# EasyBuild Maintainers Summit 2026 - when: - part 0: Fri 6 Feb 2026 16:00-17:30 CET - part 1: Mon 9 Feb 2026 14:00-16:30 CET - part 2: Thu 12 Feb 2026 14:00-16:30 CET - via Zoom - [notes of EasyBuild Maintainers Summit 2025](https://github.com/easybuilders/easybuild/wiki/Notes-from-EasyBuild-maintainer-summit-2025) - dates for 2027: - Mon 8 Feb 2027, 14:00-16:00 CET - Thu 11 Feb 2027, 14:00-16:00 CET ------------------------------------------------------- ## Topics Extra topics are welcome! ### Look back at past year - What stands out? - ... ### Online EasyBuild tutorial - most recent is the 1h intro tutorial in EESSI webinar series (May 2025) - https://www.eessi.io/docs/training-events/2025/webinar-series-2025Q2/#introduction-to-easybuild - May-June 2026? - multiple (short) sessions? ### Roadmap to EasyBuild 6.0 (wait on Micket Mon 3pm) - ETA: spring 2027 - breaking changes - whatever is deprecated now - require Python 3.9+ - deprecate stuff - only allow SHA256 checksums, deprecate everything else - features - consistent naming of easyconfig parameters, configuration options, etc. - without breaking changes, only deprecating old names - alternative modern CLI (based on [Typer](https://pypi.org/project/typer/)) - Make generic EasyBlock usable to install software ([PR#4531](https://github.com/easybuilders/easybuild-framework/pull/4531)) - [idea] Single installdir mode for easystacks (install multiple easyconfigs in the same installation folder) - [idea] Sandbox mode (stop depending on shit in the host system) - reset Slurm environment ([issue #4434](https://github.com/easybuilders/easybuild-framework/issues/4434)) ### Keeping up with contributions - ... ### Impact of EESSI on EasyBuild (positive & negative) - ... ### Adopting EESSI bot for testing EasyBuild contributions - During last EasyBuild maintainers Summit, we had ~1,000 open easyconfig PRs - Now ~600, partially thanks to merge sprints (4 in 2025: June/Aug/Oct/Dec) ### Testing on top of EESSI & on Arm - ... ### Containers - ... ### Governance - ... ### HPSF - ... ### Checksums & bundles - (Micket) - make checksums always top-level when injected - proper dict rather than list-of-dicts - required code is already there (cfr. support for `checksums.json`) - sanity check on type of value for `checksums` is getting in the way here - if that check is disabled for `checksums`, then it just works? ------------------------------------------------------- ## Fri 6 Feb 2025 attending: Åke, Alan, Davide, Bob, Mikael, Lara, Alex, Bart, Simon, Sam, Adam, Kenneth, Jasper - Simon can't join on Monday, maybe on Thursday ### AI policy (draft) - Simon - https://hackmd.io/gXwiTp8IRmCL9xihi-9LpA?view - Simon seems most critical on AI - outright banning it doesn't seem practical - first discuss internally - if maintainers are happy with it, put it up for public feedback through a docs PR - main stance is to *not* force people to use LLMs in any way - using LLMs with EasyBuild should be clearly opt-in - Adam: policy should have a version (with a changelog) - contributions done with AI - should be declared? - will people actually do that? - diff. for PRs in easyconfigs and framework - impact in framework is way bigger compared to easyconfigs - diff. policy for framework in terms of # PRs / month, size/scope of PRs - having an AI policy is partially about intent, make people think on how they use it - not only about the impact that use of AI may have - should this also cover reviewing of PRs? - maintainer is expected to understand a PR when merging it (potentially with the help of AI?) - if problem becomes too big, we could start requiring multiple reviews per (framework) PR - which has a flip side w.r.t. keeping PRs easy to merge - only for "significant" contributions - not when auto-complete is used - no cases yet for "bad" contributions to EasyBuild through AI - different policy for "trusted" contributors? - concern should be about use of AI to do nefarious things - for example by injecting a malicious patch - examples - https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md - Clang AI policy - Gentoo: https://wiki.gentoo.org/wiki/Project:Council/AI_policy - issue template to declare use of AI: https://github.com/gentoo/gentoo/blob/master/.github/pull_request_template.md ### Common toolchains: two or one per year? - pros - more focused effort, less PRs - several sites already skip either `<year>a` or `<year>b` toolchain - less confusion on what the `a` & `b` are about (alpha/beta?) - more choice w.r.t. GCC versions to use (decision is now made for us due to release cadence) - cons - "stuck" to specific dependency version for longer due to one-dep-version-per-generation rule - problem for software with fast release cycle, like PyTorch? - maybe we need to be a little bit more conservative with picking up latest software versions (like Python) - cadence - Åke doesn't care either way - Mikael has less of a concern with cadence, more with versioning scheme - `foss/2026.02` rather than `foss/2026` - leave door open for `foss/2026.12` if there's a need (avoid having to wait for `foss/2027.01`) - e.g. Python release which is way better - Kenneth: makes sense - Sam: agree with the idea, but don't use month - `foss/2026.1` (1st common toolchain in 2026), `foss/2026.2`, to keep things predictable - Simon: how to go from candidate toolchain to production toolchain? - `-dev` in version? - generic feature in framework - or flag them as experimental (in easyconfig), require option to install them - do we need to? - we rarely actually change toolchain definition - merging in `develop` isn't final, still has freedom to change things before release - majority of maintainers is in favor for aiming for 1 common toolchain per year - 8 in poll in Slack (+ 1 neutral vote) - majority of community is in favor for aiming for 1 common toolchain per year - 40 in poll in Slack (+ 2 neutral votes, 2 don't care, 4 thinking, 3 "other") - Alex: more flexibility w.r.t. multiple dependency versions - easy to do locally, but hard to contribute back - done at VUB with PyTorch: users are encouraged to `module swap` between PyTorch versions - "generations" concept on top of common toolchain? - support for range of versions for dependency - like we do OpenSSL, Java - should allow for swapping between versions of same software (like PyTorch) - introduce more flexibility - Adam: lots of pressure to use very latest R/Bioconductor - tension with staying to upstream as close as possible - Alan: cfr. `depends_on_any` feature in Lmod - RPATH linking is a problem there - Alex: biggest motivation is for stuff that doesn't link (PyTorch, Python, R, ...) - Davide: there is room for loosing things up a bit, we're now quite strict - Simon: we don't know which tools researchers are going to combine - several sites configure Lmod to not allow auto-swap (UGent, BEAR, UYork, Micket) - Åke: deeper hierarchical MNS may help? - Adam: part of answer could be a more organised way of defining a new software stack version - wider list of software that we agree on that we should cover first - should include R (for Adam) - split the work across maintainers/contributors - Mikael does a lot of work on bringing up new toolchain versions - doesn't care about some stuff, or not familiar enough with some things - would also help to populate other toolchains (`intel`, `lfoss`, `NVHPC`) - `buildtools` idea (cfr. what Kurt does on LUMI) - https://github.com/Lumi-supercomputer/LUMI-SoftwareStack/blob/main/easybuild/easyconfigs/b/buildtools/buildtools-25.09.eb - isolate more from host OS (cfr. change in `sed` that broke building stuff on LUMI) - Micket's tagbot could mark "essential" `core` tools - to help focus reviewing/merging PRs - some way of organising the work - list in a HackMD - revise during EB conf call - Alan's old PR may be helpful here: [framework #2784](https://github.com/easybuilders/easybuild-framework/pull/2784) ------------------------------------------------------- ## Mon 9 Feb 2025 ------------------------------------------------------- ## Thu 12 Feb 2025