Re: [VOTE] C++14 Upgrade

[Michael Park]

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  wrote:
> >
> >> On Mon, Feb 12, 2018 at 1:22 PM, Zhitao Li 
> >> wrote:
> >>
> >> > On Mon, Feb 12, 2018 at 11:58 AM, Michael Park 
> wrote:
> >> >
> >> > > On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li 
> >> > 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 
> >> > wrote:
> >> > > >
> >> > > > >
> >> > > > >
> >> > > > > > On Feb 11, 2018, at 10:33 PM, Michael Park  >
> >> > > 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 
> >> > 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
> >> > > > > >  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

[Andrew Schwartzmeyer]

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  wrote:

On Mon, Feb 12, 2018 at 1:22 PM, Zhitao Li  
wrote:


> On Mon, Feb 12, 2018 at 11:58 AM, Michael Park  wrote:
>
> > On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li 
> 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 
> wrote:
> > >
> > > >
> > > >
> > > > > On Feb 11, 2018, at 10:33 PM, Michael Park 
> > wrote:
> > > > >
> > > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach 
> > wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >>> On Feb 9, 2018, at 9:28 PM, Michael Park 
> 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
> > > > >  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

[Benjamin Mahler]

> 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  wrote:

> On Mon, Feb 12, 2018 at 1:22 PM, Zhitao Li  wrote:
>
> > On Mon, Feb 12, 2018 at 11:58 AM, Michael Park  wrote:
> >
> > > On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li 
> > 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 
> > wrote:
> > > >
> > > > >
> > > > >
> > > > > > On Feb 11, 2018, at 10:33 PM, Michael Park 
> > > wrote:
> > > > > >
> > > > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach 
> > > wrote:
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >>> On Feb 9, 2018, at 9:28 PM, Michael Park 
> > 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
> > > > > >  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

[Michael Park]

On Mon, Feb 12, 2018 at 1:22 PM, Zhitao Li  wrote:

> On Mon, Feb 12, 2018 at 11:58 AM, Michael Park  wrote:
>
> > On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li 
> 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 
> wrote:
> > >
> > > >
> > > >
> > > > > On Feb 11, 2018, at 10:33 PM, Michael Park 
> > wrote:
> > > > >
> > > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach 
> > wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >>> On Feb 9, 2018, at 9:28 PM, Michael Park 
> 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
> > > > >  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

[Zhitao Li]

On Mon, Feb 12, 2018 at 11:58 AM, Michael Park  wrote:

> On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li  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?


>
>
> > 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).


> Thanks!
>
> MPark
>
>
> > On Mon, Feb 12, 2018 at 8:38 AM, James Peach  wrote:
> >
> > >
> > >
> > > > On Feb 11, 2018, at 10:33 PM, Michael Park 
> wrote:
> > > >
> > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach 
> wrote:
> > > >
> > > >>
> > > >>
> > > >>> On Feb 9, 2018, at 9:28 PM, Michael Park  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
> > > >  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

[Michael Park]

On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li  wrote:

> Will there be a deprecation cycle for the proposed change?


There is no deprecation cycle for the proposed change.


> 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.

Thanks!

MPark


> On Mon, Feb 12, 2018 at 8:38 AM, James Peach  wrote:
>
> >
> >
> > > On Feb 11, 2018, at 10:33 PM, Michael Park  wrote:
> > >
> > > On Sun, Feb 11, 2018 at 6:00 PM James Peach  wrote:
> > >
> > >>
> > >>
> > >>> On Feb 9, 2018, at 9:28 PM, Michael Park  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
> > >  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
>

Re: [VOTE] C++14 Upgrade

[Zhitao Li]

Will there be a deprecation cycle for the proposed change? Our org still
uses Debian Jessie and we do not see ourselves off that before EOY.

On Mon, Feb 12, 2018 at 8:38 AM, James Peach  wrote:

>
>
> > On Feb 11, 2018, at 10:33 PM, Michael Park  wrote:
> >
> > On Sun, Feb 11, 2018 at 6:00 PM James Peach  wrote:
> >
> >>
> >>
> >>> On Feb 9, 2018, at 9:28 PM, Michael Park  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
> >  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

Re: [VOTE] C++14 Upgrade

[James Peach]

> On Feb 11, 2018, at 10:33 PM, Michael Park  wrote:
> 
> On Sun, Feb 11, 2018 at 6:00 PM James Peach  wrote:
> 
>> 
>> 
>>> On Feb 9, 2018, at 9:28 PM, Michael Park  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
>  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?

Re: [VOTE] C++14 Upgrade

[Benjamin Bannier]

+1.

I believe the spreadsheet linked in MESOS-7949 makes it pretty clear that the 
benefits outweigh the required build requirement changes.


> On Feb 10, 2018, at 6:28 AM, Michael Park  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.
> 
> Thanks!
> 
> MPark

Re: [VOTE] C++14 Upgrade

[Alex Rukletsov]

+1 (binding)

Mesos codebase seems to be ready for the upgrade (tested on Mesosphere's
internal CI). I think beginning of 2018 is the right time for this.

In addition to technical reasons mentioned by MPark, I add one more:
modernising the codebase fosters learning, fun, and makes it a more
attractive project for contributing.

A.

On 12 Feb 2018 9:41 am, "Michael Park"  wrote:

On Sun, Feb 11, 2018 at 6:00 PM James Peach  wrote:

>
>
> > On Feb 9, 2018, at 9:28 PM, Michael Park  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
 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

J

Re: [VOTE] C++14 Upgrade

[Michael Park]

On Sun, Feb 11, 2018 at 6:00 PM James Peach  wrote:

>
>
> > On Feb 9, 2018, at 9:28 PM, Michael Park  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
 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

J

Re: [VOTE] C++14 Upgrade

[James Peach]

> On Feb 9, 2018, at 9:28 PM, Michael Park  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?

J

Re: [VOTE] C++14 Upgrade

[Michael Park]

Thanks Andy!


> With respect to Windows, Visual Studio 2017 (MSVC 1910) supports C++14,
> and it's already our minimum required version. See
> https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance for
> more details. Also, we run with `/permissive-`, which disables
> non-conforming constructs.
>

This is awesome. Didn't know we compile with `/permissive-`.

But a heads up: the default GCC packages on some distributions are 4.x
> (I believe CentOS 7 is still 4.8, and Debian 8 is 4.9), so we'll need to
> update our getting started instructions to explicitly install GCC 5+.
>

Yep. As mentioned in MESOS-7949
, the investigation for
this has been done
in this spreadsheet

.

Thanks,
>
> Andy
>
> On 02/09/2018 9:28 pm, Michael Park 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.
> >
> > Thanks!
> >
> > MPark
>

Re: [VOTE] C++14 Upgrade

[Andrew Schwartzmeyer]

+1 (binding)

With respect to Windows, Visual Studio 2017 (MSVC 1910) supports C++14, 
and it's already our minimum required version. See 
https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance for 
more details. Also, we run with `/permissive-`, which disables 
non-conforming constructs.


But a heads up: the default GCC packages on some distributions are 4.x 
(I believe CentOS 7 is still 4.8, and Debian 8 is 4.9), so we'll need to 
update our getting started instructions to explicitly install GCC 5+.


Thanks,

Andy

On 02/09/2018 9:28 pm, Michael Park 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.

Thanks!

MPark

[VOTE] C++14 Upgrade

[Michael Park]

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.

Thanks!

MPark