> I guess we need to test out whether running Mesos built with newer version > of gcc (also glibc) on older version of distro is safe.
Is it possible to install the newer gcc / glibc on Jessie? It seems there are some comments on the spreadsheet that say the method posted is not safe? What about clang? https://packages.debian.org/jessie-backports/clang-3.8 On Mon, Feb 12, 2018 at 1:38 PM, Michael Park <mp...@apache.org> wrote: > On Mon, Feb 12, 2018 at 1:22 PM, Zhitao Li <zhitaoli...@gmail.com> wrote: > > > On Mon, Feb 12, 2018 at 11:58 AM, Michael Park <mp...@apache.org> wrote: > > > > > On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li <zhitaoli...@gmail.com> > > wrote: > > > > > > > Will there be a deprecation cycle for the proposed change? > > > > > > > > > There is no deprecation cycle for the proposed change. > > > > > > > I take that the moment we decide this, c++ features which requires gcc > >=5 > > will be used? > > > > This is correct. I would be against keeping the codebase C++11 and merely > compiling in C++14 since it'll only be a matter of time before a C++14 > feature sneaks in > and we're no longer 11 compatible. > > > > > > > > > > Our org still uses Debian Jessie and we do not see ourselves off that > > > > before EOY. > > > > > > > > > > > This is great! Thanks for sharing. Could you please clarify what "uses" > > > mean here? > > > I'm guessing it means that the dev servers that you develop on run > > Jessie, > > > but > > > wanted to clarify. > > > > > > > A (big) part of our production fleet, our dev servers and our package > > release process are all using Debian Jessie. > > > > I guess we need to test out whether running Mesos built with newer > version > > of gcc (also glibc) on older version of distro is safe. If so, my team > will > > only have dev environment to worry about (which is at a much smaller > scale > > to deal with). > > > > Okay, it seems like you'll probably need more time to do this probably than > the Feb 21? > If so, could you -1 on the vote and we can wait till you feel comfortable > with this bump? > > > > > Thanks! > > > > > > MPark > > > > > > > > > > On Mon, Feb 12, 2018 at 8:38 AM, James Peach <jpe...@apache.org> > > wrote: > > > > > > > > > > > > > > > > > > > > On Feb 11, 2018, at 10:33 PM, Michael Park <mcyp...@gmail.com> > > > wrote: > > > > > > > > > > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach <jpe...@apache.org> > > > wrote: > > > > > > > > > > > >> > > > > > >> > > > > > >>> On Feb 9, 2018, at 9:28 PM, Michael Park <mp...@apache.org> > > wrote: > > > > > >>> > > > > > >>> I'm going to put this up for a vote. My plan is to bump us to > > C++14 > > > > on > > > > > >> Feb > > > > > >>> 21. > > > > > >>> > > > > > >>> The following are the proposed changes: > > > > > >>> - Minimum GCC *4.8.1* => *5*. > > > > > >>> - Minimum Clang *3.5* => *3.6*. > > > > > >>> - Minimum Apple Clang *8* => *9*. > > > > > >>> > > > > > >>> We'll have a standard voting, at least 3 binding votes, and no > > -1s. > > > > > >> > > > > > >> +0 > > > > > >> > > > > > >> What’s the user benefit of this change? > > > > > >> > > > > > > > > > > > > Some of the features I've described in MESOS-7949 > > > > > > <https://issues.apache.org/jira/browse/MESOS-7949> are: > > > > > > > > > > > > - Generic lambdas > > > > > > - New lambda captures (Proper move captures!) > > > > > > - SFINAE result_of (We can remove stout/result_of.hpp) > > > > > > - Variable templates > > > > > > - Relaxed constexpr functions > > > > > > - Simple utilities such as std::make_unique > > > > > > - Metaprogramming facilities such as decay_t, index_sequence > > > > > > > > > > Are these all internal though? Maybe move captures could yield some > > > > > performance improvements? > > > > > > > > > > > > > > > > > > > > > > -- > > > > Cheers, > > > > > > > > Zhitao Li > > > > > > > > > > > > > > > -- > > Cheers, > > > > Zhitao Li > > >
