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
>

Reply via email to