---
# System prepended metadata

title: 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

