search

easybuilders / easybuild

EasyBuild - building software with ease
http://easybuild.io
GNU General Public License v2.0
456 stars 142 forks source link

Toolchain Support Policy - EasyBuild 5 #872

Closed branfosj closed 1 year ago

branfosj commented 1 year ago

Work has started on EasyBuild 5 and we, the EasyBuild maintainers, are requesting community feedback on some potential changes. If you will be impacted by this proposed change then please leave feedback below.

Proposed Change

For the central EasyBuild repositories, we will support a set of toolchain generations. In year X (example using 2023):

Background

The central easyconfigs repository is intended to provide references easyconfigs. For the reference easyconfigs we aim to have only one version of a software being used as a dependency in each toolchain generation. (There are exceptions, but we aim to keep these limited.)

Sites and users can then supplement these easyconfigs via there own collection of easyconfigs. This additional collection is added via the robot search path.

Benefits

Drawbacks

Alternatives

Alternative 1

As above, but with each step being 1 year older. So, review (X-3); deprecate and close (X-4); and archive (X-5)

Alternative 2

Base it on the last 6 common toolchains, instead of years. So, review (last 6); deprecate and close (7); and archive (8).

jfgrimm commented 1 year ago

I think I'd prefer to deprecate/archive based on the released toolchains (alternative 2), since that will give a constant number of supported toolchains. Perhaps we should deprecate 7 & 8 though, and archive 9+ (which would put us more in line with when toolchains are archived with the main proposal)?

boegel commented 1 year ago

@branfosj There are currently only 4 supported toolchain generations.

I guess this could be clarified:

There are currently (May 2023) only 4 supported toolchain generations (`2021a`, `2021b`, `2022a`, `2022b`), since the `2023a` common toolchains have not been defined yet (but it's a work in progress).
boegel commented 1 year ago

I think I'd prefer to deprecate/archive based on the released toolchains (alternative 2), since that will give a constant number of supported toolchains. Perhaps we should deprecate 7 & 8 though, and archive 9+ (which would put us more in line with when toolchains are archived with the main proposal)?

I think I agree with @jfgrimm here, since then the moment when we deprecate/archive a toolchain is also clear: as soon as the next common toolchain is defined. Also, with the year-based approach we would suddenly have to deprecate not 1 but 2 toolchains, and archive 2 toolchains at the start of a new year (but that may slip in February, etc.).

By tying the deprecation/archiving of old toolchain versions to the release of a new common toolchain version, we reduce the load a bit (deprecate 1 + archive 1, rather than 2 each), and we can make that process part of the "release" process of a new common toolchain version (so make those changes in the same EasyBuild release, and bump the minor version).

So, to make this approach more concrete:

a) support the 5 most recent common toolchain versions (currently that would be 2022b, 2022a, 2021b, 2021a, 2020b); b) deprecate the next 2 common toolchain versions (currently 2020a and 2019b) - and actively close PRs that (only) touch easyconfigs of that generation - we could make the easyconfigs test suite aware of this; c) archive easyconfigs for older common toolchain versions (currently 2019a, and older);

Maybe the 5 in a) should be 6, I guess that can be up for discussion/vote.

When we define the 2023a common toolchain versions, we would then archive easyconfigs using a 2019b toolchain, and deprecate ones using a 2020b toolchain.

branfosj commented 1 year ago

@branfosj There are currently only 4 supported toolchain generations.

I guess this could be clarified:

There are currently (May 2023) only 4 supported toolchain generations (`2021a`, `2021b`, `2022a`, `2022b`), since the `2023a` common toolchains have not been defined yet (but it's a work in progress).

And

When we define the 2023a common toolchain versions ...

With these, we'll need to agree on what qualifies as having defined common toolchain. I'm guessing currently this is foss/X and intel/X in an EB release.

hajgato commented 1 year ago

I am in favor to deprecate/archive versions when a new one is released, not based on years. So we keep a constant amount of "supported" toolchains.

boegel commented 1 year ago

When we define the 2023a common toolchain versions ...

With these, we'll need to agree on what qualifies as having defined common toolchain. I'm guessing currently this is foss/X and intel/X in an EB release.

To me it means having easyconfigs for foss/2023a and intel/2023a in the develop branch (not necessarily in a release). As soon as those PRs are merged, we can actively start the deprecated/archiving of the old toolchains (so those changes are included in the next EasyBuild release, along with the new common toolchain version).

We shouldn't do this yet when defining 2023a though (which should happen soon), so the community has some time to provide feedback to this proposal?

branfosj commented 1 year ago

We shouldn't do this yet when defining 2023a though (which should happen soon), so the community has some time to provide feedback to this proposal?

My intention is that we start this later this year. A possible timeline:

Currently we have back to 2016a. So if we go with https://github.com/easybuilders/easybuild/issues/872#issuecomment-1582090382 we'd have 7 to archive (2016a, 2016b, 2017a, 2017b, 2018a, 2018b, and 2019a) and the addition of the 2023a common toolchains would add 2019b to this list.

signalbox2 commented 1 year ago

I agree with jfgrimm, as for the less-used software (and we as using bioinformatics packages) there is often no update after the initial burst of effort when the associated paper is published and people want to try it out. So it's not uncommon to want to use quite old easyconfigs as being less effort than updating them to a current toolchain. Myself I try if possible to only use easyconfigs from one toolchain per year to limit sprawl.

boegel commented 1 year ago

@branfosj Maybe we should wait until we switch over from the 5.0.x branch to develop for the development of EasyBuild 5.x, before we start making breaking changes in policy w.r.t. easyconfigs we archive & accept PRs for?

branfosj commented 1 year ago

Thanks everyone for the feedback. I believe we've agreed on the following.

Supported Toolchain Generations Policy

For the central EasyBuild repositories, we will support a set of toolchain generations.

Notes

Background

The central easyconfigs repository is intended to provide references easyconfigs. For the reference easyconfigs we aim to have only one version of a software being used as a dependency in each toolchain generation. (There are exceptions, but we aim to keep these limited.)

Sites and users can then supplement these easyconfigs via there own collection of easyconfigs. This additional collection is added via the robot search path.

Example

As of July 2023 the latest toolchain generation is 2023a.

branfosj commented 1 year ago

I've PR-ed this: https://github.com/easybuilders/easybuild-docs/pull/200