You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Andrew Schwartzmeyer <an...@schwartzmeyer.com> on 2018/04/13 19:49:35 UTC
Re: [VOTE] C++14 Upgrade
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 <zh...@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 <zh...@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 <jp...@apache.org>
>> > wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > > > On Feb 11, 2018, at 10:33 PM, Michael Park <mc...@gmail.com>
>> > > wrote:
>> > > > > >
>> > > > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach <jp...@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
>> >
>>
Re: [VOTE] C++14 Upgrade
Posted by Michael Park <mp...@apache.org>.
It failed. I implicitly took Uber's dev environment concern as a -1.
On Fri, Apr 13, 2018 at 3:49 PM Andrew Schwartzmeyer <
andrew@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 <zh...@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 <zh...@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 <jp...@apache.org>
> >> > wrote:
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > > > On Feb 11, 2018, at 10:33 PM, Michael Park <mcypark@gmail.com
> >
> >> > > wrote:
> >> > > > > >
> >> > > > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach <
> jpeach@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
> >> >
> >>
>