I think the idea of bumping up just easyconfigs is a good one. A lot of sites that are contributing back are running essentially development easyconfigs in production and I think we should be able to accept a faster moving ECs versioning against somewhat slower moving EBs and slow versioned framework.
I don't have a great idea for the versioning, but maybe we can have a hierarchical versioning (or just tag the new config releases with a -2). Maybe rather than holding on to v2 we could do <framework>.<blocks>.<config> (just to stick to triples, because the versioning world seems to prefer three)? On Fri, Jul 10, 2015 at 5:10 AM Kenneth Hoste <[email protected]> wrote: > Update: > > A release candidate for GCC 5.2 is available, but the actual release won't > be there before mid next-week (see > https://gcc.gnu.org/ml/gcc/2015-07/msg00073.html). > > Here's what I propose: we stick to including GCC 5.2 in the 2015b common > toolchains. > I consider this important, since GCC 5.2 is a bugfix release over GCC 5.1 > (no new features, cfr. new GCC versioning scheme). > > This does imply that the easyconfigs for the 2015b toolchains will not be > included in the upcoming EB v2.2.0 (which is planned for mid-next week); I > don't want to rush these in without extensive testing once GCC 5.2 is there. > > I can look into an EasyBuild v2.2.1 release early August, which would > basically be v2.2.0 + easyconfigs for 2015b toolchains and software built > with that toolchain. > > Feedback on this, especially from sites who are planning on > installing/using foss/2015b and/or intel/2015b? > > If agreed, I can already bump the GCC version in the open foss/2015b and > intel/2015b PRs, to get them ready for testing once GCC 5.2 is out. > > > regards, > > Kenneth > > > On 29/06/15 17:22, Robert Schmidt wrote: > > If the release candidate is available when they say and we can do most of > the testing against that, I don't see it being a big risk to try and > include it and it won't hurt to help test the RC. > > I see that they have changed their versioning so that 5.2 is a less > significant change than it would have been under the 4.x series. > > On Mon, Jun 29, 2015 at 6:59 AM Kenneth Hoste <[email protected]> > wrote: > >> Hi all, >> >> GCC 4.8.5 and 4.9.3 were released last week, but more importantly w.r.t. >> the 2015b common toolchains: GCC 5.2.0 (bugfix release for GCC 5.1.0) is >> planned to be released July 10th 2015 (see >> https://gcc.gnu.org/ml/gcc/2015-06/msg00202.html). >> >> That opens up the discussion again: should we hold off finalizing the >> foss/2015b (+ gompi/2015b) and intel/2015b definitions until GCC 5.2.0 >> is available, so we can use it as a base rather than our current pick >> GCC 5.1.0? >> >> If the release of GCC 5.2 happens effectively on July 10th, it may be >> doable to still make that change and have sufficient time for >> (re)testing, but it'll be quite tight... >> >> Thoughts? >> >> >> regards, >> >> Kenneth >> >> >> >> On 17/06/15 12:50, Kenneth Hoste wrote: >> > Hello EasyBuilders, >> > >> > With summer approaching rapidly (I'm sure you're aware), it's time to >> > look into defining the 2015b update of the common compiler toochains >> > 'foss' and 'intel'. >> > >> > For those of you not aware yet: the common toolchains are an attempt >> > at synchronizing the major toolchains being used with EasyBuild across >> > different sites, to try and reap the benefits of each others efforts >> > even more. The idea is to refresh these toolchains every 6 months. >> > >> > It's important to note that we are not enforcing these toolchains on >> > anyone: it's up to you whether you join in or not, and other >> > toolchains and toolchain versions will of course remain supported as >> > they have been in the past (with the exception of some old toolchains >> > that I'd like to deprecate sometime soon (goalf, iqacml), but more on >> > that later). >> > >> > I've taken the liberty to come up with a proposal for foss/2015b and >> > intel/2015b, see also the respective pull requests >> > https://github.com/hpcugent/easybuild-easyconfigs/pull/1695 and >> > https://github.com/hpcugent/easybuild-easyconfigs/pull/1696. >> > >> > foss/2015b: >> > GCC v5.1.0 >> > binutils/2.25 (which implies also including zlib/1.2.8) >> > OpenMPI v1.8.5 (note: with 1.8.6 likely to be released very soon, >> > this may get bumped before the definition is cast into stone) >> > OpenBLAS 0.2.14 >> > FFTW 3.3.4 >> > ScaLAPACK 2.0.2 >> > >> > intel/2015b: >> > (GCC v5.1.0 + binutils/2.25) >> > Intel compilers (icc + ifort) 2015.3.187 (a.k.a. 15.0.3.187) >> > Intel MPI v5.0.3.048 >> > Intel MKL v11.2.3.187 >> > >> > A couple of notes on this: >> > >> > * The most significant change is including binutils into these >> > toolchains (which also reels in zlib). >> > The reason for this is analogous to the reason for including GCC in >> > the intel toolchain: to be independent from what the OS provides. >> > This is very relevant for RHEL6-based Haswell systems, where the >> > standard binutils version included is too old to support AVX2 (cfr. >> > https://github.com/hpcugent/easybuild-easyconfigs/issues/1605), as >> > several EasyBuild sites have discovered. >> > >> > * After careful consideration, we bumped the GCC version to the latest >> > an greatest 5.1.0, despite it being a new major version. >> > There are several reasons for this, including better OpenMP 4.0 and >> > C+11 support in GCC 5.1.0, and the 2nd most recent 4.9.2 being rather >> > old (Oct'14). >> > >> > Other communities have explored the impact of moving to GCC 5.1.0 >> > (e.g. >> > >> https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html >> ). >> > Although the impact significant, it's limited to a small set of >> > packages, and the pros outweigh the cons in my opinion. >> > >> > * Other changes include bumping the versions to the latest and greatest. >> > >> > >> > Preliminary testing using Python and Boost has shown that rebuilding >> > existing 2014b easyconfigs doesn't yield too much surprises. >> > >> > I'm planning to run further tests in the coming weeks rebuilding >> > existing easyconfigs using the 2014b toolchains, but unless major >> > issues pop up, I consider these 2015b toolchain definitions solid. >> > >> > >> > Feedback, suggestions and/or remarks are much appreciated, both in >> > this mail thread and via the respective pull requests. >> > >> > Unless major concerns come forward, my intention is to include these >> > 2015b toolchains + several easyconfigs using them in the next >> > EasyBuild release (v2.2.0, planned for end of June/early July). >> > >> > Last but not least: please refrain from using these 2015b toolchains >> > in production until the respective pull requests are merged. Until >> > then, the toolchain definitions may still be tweaked (and probably >> > will be for foss/2015b w.r.t. the OpenMPI version)! >> > >> > >> > regards, >> > >> > Kenneth >> >> >
