It failed. I implicitly took Uber's dev environment concern as a -1. On Fri, Apr 13, 2018 at 3:49 PM Andrew Schwartzmeyer < and...@schwartzmeyer.com> wrote:
> Do we know where this went? When are we doing the upgrade, is something > still blocking us? > > Thanks, > > Andy > > On 02/12/2018 2:03 pm, Benjamin Mahler wrote: > >> 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 > >> > > >> >
