Hi Joachim,
On 30/09/16 11:41, Joachim Hein wrote:
Hi Kenneth,
I had a look into the notes and think some extra discussion is
required on the “discontinuation business”. Not sure where to start
this, so I am replying here.
I occasionally get requests for “historic” and “fossile” versions of
packages - not all of them totally unreasonable, e.g. API change in
application. Examples include OpenFOAM and Gromacs. Prior to
EasyBuild I would have said no, unless you give me a strong reason.
With EasyBuild, I check whether a to the user acceptable version is in
the “back catalog” and try to easybuild it. If it builds without much
issue I roll it out. If it breaks I am not worse off than without
EasyBuild. Typically I build with the “old” machinery of the time
(that is what it was tested with) - installing a legacy GCC and
OpenMPI in EB is typically easy.
I think here are two big selling points of EB, which we perhaps not
even push enough.
* Better user experience - many requests for legacy versions can
easily be supported. It is typically easier to just build it
instead of discussing with the user.
Hah, I like this, can I quote you on that in a future presentation? This
is a really good selling point of EasyBuild indeed: it makes it so easy
to comply to the user's wishes that you can just do so without losing
too much time... :-)
* Building software with a tried and tested software stack gives
stability against bugs introduced in the latest version
So, how do you plan to do the discontinuation? Removing toolchain
versions will break everything that builds on that toolchain. Keeping
them as “unsupported” seems the way forward to me. That is, it is
still available in some form but no longer tested and fixed. If they
still work, good, if they are broken: work around it. Introducing an
“attic” type concept might be an idea. Depreciated packages get to
the attic. A typical “eb -S” would not show them, but e.g. an extra
“attic” or “antique” option would.
My idea is exactly this: archiving the easyconfigs for both the
deprecated toolchains themselves and any easyconfig that uses these
deprecated toolchains. You would then have to use something like
--consider-archived-easyconfigs, and/or accept a big fat warning telling
you that you these easyconfigs are no longer tested or actively
maintained, and that you should only use them 'at your own risk'.
The main idea is to get these easyconfigs out of view, disencourage
their usage, and no longer include them in regression testing.
There's little reason is totally removing them imho...
regards,
Kenneth
Best wishes
Joachim
On 29 Sep 2016, at 18:36, Kenneth Hoste <[email protected]
<mailto:[email protected]>> wrote:
notes are available at
https://github.com/hpcugent/easybuild/wiki/Conference-call-notes-20160929
Next conf call is planned for Wed Oct 12th 5pm CET, cfr.
https://plus.google.com/events/cir0grjke0kbfutgmgp2v9nfm3s
On 27/09/16 21:03, Kenneth Hoste wrote:
Dear EasyBuilders,
The next EasyBuild conf call is planned for *Thursday* September
29th 2016, 5pm CET;
see also https://plus.google.com/events/c8tqca652anjfqblifjam5q9s6k .
(just this once, I've planned it on a Thursday rather than a
Wednesday due to an agenda conflict)
Topics I have in mind include:
* (very early) outlook to EasyBuild v3.0: default config changes,
(minor) backwards-incompatible changes
* deprecating toolchains: what & how
* see also
https://github.com/hpcugent/easybuild/wiki/Deprecated-toolchains
* update on support for RPATH (WIP)
*
https://github.com/hpcugent/easybuild-framework/compare/develop...boegel:rpath?expand=1
* Q&A
Suggestions for additional topics are welcome.
Please let me know if you're planning to attend this conf call.
More information about the EasyBuild conf calls is available at
https://github.com/hpcugent/easybuild/wiki/Conference-calls .
regards,
Kenneth
