I like what Joachim suggest about the "attic" concept. Old/deprecated
easyconfigs provided "as-is" but not included in the regular tests. I think
I suggested something similar in one of the conf calls.

About how to search in the legacy easyconfigs I would prefer a different
approach . What I would suggest is that instead of skipping those ones when
doing "eb --search" I would still show them when doing a regular search
with "eb --search" but in case the search result comes from the "attic"
print a big disclaimer saying something like "I found this legacy
easyconfig in the attic but we aware that this is not tested". Or maybe in
case some legacy stuff is found print a url which links to the docs
sections explaining what is the attic.

My fear about not searching by default in legacy easyconfigs is that many
people would skip the extra option needed to search in the legacy
easyconfigs and they wouldn't notice that it's there. Many times even if
the legacy easyconfig doesn't work it can be useful as a start point to
write a new one so it's useful to find them easily. I know many of us are
sysadmins and we like to reply RTFM but easybuild has many many different
config flags and it's easy to skip this one ( even for a sysadmin ;)

regards,
Pablo.

2016-09-30 11:41 GMT+02:00 Joachim Hein <joachim.h...@math.lu.se>:

> 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.
>    - 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.
>
> Best wishes
>   Joachim
>
>
>
> On 29 Sep 2016, at 18:36, Kenneth Hoste <kenneth.ho...@ugent.be> 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
>
>
>
>


-- 
Pablo Escobar López
HPC systems engineer
sciCORE, University of Basel
SIB Swiss Institute of Bioinformatics
http://scicore.unibas.ch

Reply via email to