Re: http://mesos.apache.org/downloads/ is not up to date

[Benjamin Mahler]

Thanks for pointing this out Adam, I've added mpark who is the release
manager for 1.3.2.

On Tue, Feb 6, 2018 at 6:12 AM, Adam Cecile  wrote:

> Hi guys,
>
>
> Did you notice Mesos 1.3.2 is missing from the official download page ?
>
> http://mesos.apache.org/downloads/
>
>
> Regards, Adam.
>
>

Reminder: Design Doc for Mesos CLI Re-design

[Benjamin Mahler]

I've heard a lot of interest in there being investment in the mesos CLI.
For those that are interested, please take a look at the re-design doc and
share your feedback:

https://docs.google.com/document/d/1r6Iv4Efu8v8IBrcUTjgYkvZ32WVsc
gYqrD07OyIglsA/edit

Feel free to make comments in the doc, suggest commands that you think
would be useful, or share any high level feedback, questions, or concerns
here and Kevin / Armand can answer them.

Ben

Re: Looking for shepherd

[Benjamin Mahler]

In case others also look at this thinking this still needs a shepherd, this
has been committed.

On Mon, Feb 12, 2018 at 6:39 AM, Tomek Janiszewski 
wrote:

> I need someone to review and merge this change
> https://reviews.apache.org/r/65569/
> It should fix ARM tests.
>

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

[GitHub] mesos pull request #264: WIP: docker image build automation

[bbannier]

Github user bbannier closed the pull request at:

https://github.com/apache/mesos/pull/264


---

[GitHub] mesos pull request #264: WIP: docker image build automation

[bbannier]

GitHub user bbannier opened a pull request:

https://github.com/apache/mesos/pull/264

WIP: docker image build automation



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/bbannier/mesos t/docker_image_build

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/mesos/pull/264.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #264


commit e47136f68105717ed9c177e283ce2fd4ab831ddd
Author: Benjamin Bannier 
Date:   2018-02-12T10:25:36Z

Moved some docker image setups to dedicated directory.

commit 7af8ea15110ed56f4d8855531c7c07c5dc96a93c
Author: Benjamin Bannier 
Date:   2018-02-12T11:32:26Z

Docker image build setup.




---

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: Introducing `support/mesos-build.sh`

[Tomek Janiszewski]

How can I use it for our ARM CI?

JOBS=16 OS=arm64v8/ubuntu:16.04  ./support/mesos-build.sh
+ set -e
+ set -o pipefail
+ : arm64v8/ubuntu:16.04
+ : autotools
+ : gcc
+ : '--verbose --disable-libtool-wrappers'
+ : 'GLOG_v=1 MESOS_VERBOSE=1'
+ : 16
++ git rev-parse --show-toplevel
+ MESOS_DIR=/home/janisz/mesos
++ git diff-index --quiet HEAD --
+ docker run --rm -v /home/janisz/mesos:/SRC:Z -e BUILDTOOL=autotools -e
COMPILER=gcc -e 'CONFIGURATION=--verbose --disable-libtool-wrappers' -e
'ENVIRONMENT=GLOG_v=1 MESOS_VERBOSE=1' -e JOBS=16
mesos/mesos-build:arm64v8/ubuntu-16.04
docker: invalid reference format.
See 'docker run --help'.


czw., 8 lut 2018 o 07:38 użytkownik Michael Park  napisał:

> The first run looks good!
> https://builds.apache.org/job/Mesos-Buildbot/4890/
>
> [image: Screen Shot 2018-02-07 at 10.30.51 PM.png]
> On Wed, Feb 7, 2018 at 8:39 PM Michael Park  wrote:
>
> > Yep, Just landed! Waiting for
> https://builds.apache.org/job/Mesos-Buildbot to
> > pick it up.
> >
> > On Wed, Feb 7, 2018 at 8:27 PM Vinod Kone  wrote:
> >
> >> Yay, thanks MPark! Has the change landed already?
> >>
> >> On Wed, Feb 7, 2018 at 8:23 PM, Michael Park  wrote:
> >>
> >> > Many of you probably know that we currently have
> >> `support/docker-build.sh`
> >> > to power our CI for our various configurations. One of the problems
> for
> >> us
> >> > has been that we create a `Dockerfile` ad-hoc and invoke `docker
> build`
> >> > with it. This is very inefficient and also leads to flaky issues
> around
> >> > `apt-get install`.
> >> >
> >> > I've introduced `support/mesos-build.sh` which operates off of docker
> >> > images hosted on Dockerhub instead, and should aid in bringing us
> faster
> >> > and more stable CI results!
> >> >
> >> > As a bonus, we now also test Clang on the CentOS 7!
> >> >
> >> > Thanks,
> >> >
> >> > MPark
> >> >
> >>
> >
>

Looking for shepherd

[Tomek Janiszewski]

I need someone to review and merge this change
https://reviews.apache.org/r/65569/
It should fix ARM tests.

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: Soliciting Hackathon Ideas

[Alex Rukletsov]

Judith —

we have newbie and newbie++ labels [1]. To help people land their changes
at the end of a hackathon, we should find shepherds for issues before
giving them out to folks. Shepherds should have time for reviews and an
idea about the approach.

[1]
https://issues.apache.org/jira/browse/MESOS-8338?jql=labels%20in%20(newbie%2C%20%22newbie%2B%2B%22)%20AND%20project%20%3D%20MESOS%20AND%20status%20!%3D%20Resolved%20

On Fri, Feb 9, 2018 at 10:07 PM, Judith Malnick 
wrote:

> Hi all, these are great! Are they currently captured in Jira tickets or
> issues of some kind? If we had a beginner label we might be able to
> advertise those issues in other hackathons like Hacktober too :) I'd be
> happy to create tickets for the issues but I don't want to accidentally
> create a ton of duplicates if they already exist.
>
> On Wed, Feb 7, 2018 at 6:31 PM, Andrew Schwartzmeyer <
> and...@schwartzmeyer.com> wrote:
>
> > Thanks all for the ideas! (And keep them coming if you have more, it's
> not
> > for another couple weeks.) I'll make sure to put together a list and run
> it
> > by a few of you before I fly out.
> >
> >
> > On 02/07/2018 3:22 pm, Benjamin Mahler wrote:
> >
> >> -list to bcc
> >>
> >> Hey Tim! Sorry that this fell through the cracks, Vinod and I can
> shepherd
> >> this.
> >>
> >> What time zone are you in? We can set up a hangout to go over it.
> >>
> >> Ben
> >>
> >> On Wed, Feb 7, 2018 at 8:13 AM, Timothy Anderegg <
> >> timothy.ander...@gmail.com
> >>
> >>> wrote:
> >>>
> >>
> >> I've been looking for a new shepherd for that for a while, if there are
> >>> any
> >>> takers I'm happy to rebase against the latest code!
> >>>
> >>> Tim
> >>>
> >>> On Wed, Feb 7, 2018 at 11:10 AM James Peach  wrote:
> >>>
> >>> >
> >>> >
> >>> > > On Feb 6, 2018, at 11:21 PM, Benjamin Mahler 
> >>> wrote:
> >>> > >
> >>> > > +1 Versioned documentation would be heroic!
> >>> >
> >>> > Based on https://reviews.apache.org/r/52064/ ?
> >>> >
> >>> > >
> >>> > > On Tue, Feb 6, 2018 at 5:49 PM Vinod Kone 
> >>> wrote:
> >>> > >
> >>> > >> Versioned documentation!
> >>> > >>
> >>> > >> Sent from my iPhone
> >>> > >>
> >>> > >>> On Feb 6, 2018, at 4:37 PM, Benjamin Mahler 
> >>> > wrote:
> >>> > >>>
> >>> > >>> A couple of ideas from the performance related working group:
> >>> > >>>
> >>> > >>> -Use protobuf arenas for all non-trivial outbound master messages
> >>> > (easy)
> >>> > >>> This can be done piecemeal.
> >>> > >>> -Use move semantics (take a Message&&) in all of the master
> message
> >>> > >>> handlers to reduce copying (medium) This one can be done
> piecemeal.
> >>> For
> >>> > >>> example Master::statusUpdate would be a good one to start with.
> >>> > >>> -Audit the Registrar code to use move semantics to reduce copying
> >>> > >> (medium)
> >>> > >>>
> >>> > >>> If there are any UI programmers:
> >>> > >>>
> >>> > >>> -Consider a webui "refresh", try to find a new set of fonts and
> >>> style,
> >>> > >>> could be fun.
> >>> > >>>
> >>> > >>> On Fri, Feb 2, 2018 at 12:47 PM, Andrew Schwartzmeyer <
> >>> > >>> and...@schwartzmeyer.com> wrote:
> >>> > >>>
> >>> >  Hello all,
> >>> > 
> >>> >  Next month I'll be attending HackIllinois (
> >>> https://hackillinois.org/)
> >>> > >> as
> >>> >  an open-source mentor. It's a huge student-run hackathon at the
> >>> > >> University
> >>> >  of Illinois at Urbana-Champaign, running from February 23rd to
> the
> >>> > 25th.
> >>> >  Students from a multitude of schools will be attending (they
> even
> >>> bus
> >>> > >> them
> >>> >  in). The hackathon has an open-source focus, and while there
> will
> >>> be
> >>> > >> many
> >>> >  projects for the students to work on, I want to make sure Mesos
> >>> gets
> >>> > >> some
> >>> >  attention too.
> >>> > 
> >>> >  I am asking you all for open issues and new ideas for small,
> >>> >  beginner-friendly projects that could fit a two-day Hackathon
> >>> project.
> >>> > >> For
> >>> >  Mesos, I'm looking through our open issues labeled "easyfix",
> >>> > >> "beginner",
> >>> >  or "newbie", which actually returns 74 results! If you have
> >>> anything
> >>> > in
> >>> >  particular that you think would be a good fit, please let me
> know.
> >>> I'd
> >>> > >> like
> >>> >  to go with a list of vetted issues so I don't accidentally start
> >>> some
> >>> >  students in on a giant can of worms. Our excellent new Beginner
> >>> > >> Contributor
> >>> >  Guide will be a huge help too.
> >>> > 
> >>> >  Thanks,
> >>> > 
> >>> >  Andy
> >>> > 
> >>> >  P.S. If any of you also want to attend, let me know, and I'll
> get
> >>> you
> >>> > in
> >>> >  touch with their director.
> >>> > 
> >>> > >>
> >>> >
> >>> >
> >>>
> >>>
>
>
> --
> Judith Malnick
> Community Manager
> 310-709-1517 <(310)%20709-1517>
>

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