Shepherd request

[Disha Singh]

Can anyone be the shepherd for :
https://issues.apache.org/jira/browse/MESOS-3161

I would need help in inserting proper data at the right places. Thanks!

Re: Updation

[haosdent]

Could you create a ticket in https://issues.apache.org/jira/browse/MESOS to
track this?

On Thu, Jan 28, 2016 at 8:58 AM, Disha Singh 
wrote:

> Does the file:
> /src/java/MESOS-MAVEN-README
> need any updation.
>
> I'm doubtful as it mentions mesos-0.19.0 even now.
>



-- 
Best Regards,
Haosdent Huang

Re: Apache Mesos Community Sync

[Michael Park]

Our next community sync will be tomorrow January 28, 2016 at 3pm PST.

To join in person, come to Mesosphere HQ at 88 Stevenson St. and see the
reception on the 2nd floor.

Please add your agenda items to the Google Doc

!

P.S. Subscribe to the Mesos events calendar at
https://calendar.google.com/calendar/embed?src=2hecvndc0mnaqlir34cqnfvtak%40group.calendar.google.com
for
future meetings and events.

Thanks,

MPark.

On 13 January 2016 at 13:43, Michael Park  wrote:

> Our next community sync will be tomorrow Jan 14 at 9pm PST (looks like I
> mistakenly said Jan 15 in my last email, sorry!).
>
> We'll host this one online only, and will send out links to Hangouts and
> OnAir tomorrow.
>
> Please add your agenda items to the Google Doc
> ,
> and subscribe to the Mesos events calendar at
> https://calendar.google.com/calendar/embed?src=2hecvndc0mnaqlir34cqnfvtak%40group.calendar.google.com
>  for
> future meeting schedules.
>
> Thanks,
>
> MPark.
>
> On Tue, Dec 22, 2015 at 7:12 PM Michael Park  wrote:
>
>> Our last community sync was supposed to be on Dec 17, unfortunately we
>> missed it. Sorry if anyone was looking for where it was happening.
>>
>> The next one would have been on Dec 31, but given that most people will
>> likely be out for holidays I've updated the calendar to cancel it.
>>
>> Our next meeting is scheduled for Jan 15 at 9pm PST, and we'll send out
>> more detailed information as it approaches.
>>
>> Thanks,
>>
>> Happy holidays!
>>
>> MPark.
>>
>> On Thu, Dec 3, 2015 at 2:46 AM Michael Park  wrote:
>>
>>> Our next community sync will be tomorrow December 3 at 3pm PST.
>>>
>>> To join in person, come to Mesosphere HQ at 88 Stevenson St. and see the
>>> reception on the 2nd floor.
>>>
>>> Please add your agenda items to the Google Doc
>>> 
>>> !
>>>
>>> Subscribe to our Mesos events calendar at
>>> https://calendar.google.com/calendar/embed?src=2hecvndc0mnaqlir34cqnfvtak%40group.calendar.google.com
>>>  for
>>> future meeting schedules.
>>>
>>> Thanks,
>>>
>>> MPark.
>>>
>>> We will use Hangouts + YouTube OnAir, the links will be shared on IRC
>>> and via email shortly before the meeting.
>>>
>>> Please add agenda items to the Google Doc
>>> 
>>> !
>>>
>>> Thanks,
>>>
>>> MPark.
>>>
>>> On Thu, Nov 19, 2015 at 12:01 PM Michael Park  wrote:
>>>
 Greg Mann and I will be hosting the community sync on the web today
 (November 19) at 9pm PST.

 We will use Hangouts + YouTube OnAir, the links will be shared on IRC
 and via email shortly before the meeting.

 Please add agenda items to the Google Doc
 
 !

 Thanks,

 MPark.

 On Thu, Nov 5, 2015 at 3:20 PM Adam Bordelon 
 wrote:

> Sorry for the late link, but you can see the youtube stream (and
> after-the-fact video) at: http://youtu.be/rJyT8xDzhcA
>
> We also have a hangout link for those with agenda items, or those who
> have
> lengthy things to discuss (ask if you need the link). For brief
> questions,
> you can add them to the agenda or ask in IRC and I will relay them for
> you.
>
> On Wed, Nov 4, 2015 at 4:42 PM, Adam Bordelon 
> wrote:
>
> > Sounds great! Please join us at Mesosphere HQ, 88 Stevenson St., SF
> at 3pm
> > Pacific tomorrow.
> > We will use youtube-onair again, links to be posted to IRC/email
> shortly
> > before the meeting.
> >
> > Please add agenda items:
> >
> >
> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit#heading=h.za1f9dpxisdr
> >
> > On Wed, Nov 4, 2015 at 4:25 PM, Jie Yu  wrote:
> >
> >> Adam, since most of the Twitter folks are OOO this week. I chatted
> with
> >> Artem/Vinod. we think it makes sense to host the sync at Mesosphere
> >> tomorrow.
> >>
> >> - Jie
> >>
> >> On Wed, Nov 4, 2015 at 4:22 PM, Adam Bordelon 
> wrote:
> >>
> >>> It's been a while since our last community sync, and tomorrow,
> Thursday
> >>> Nov 5th shows up on my calendar as a 3pm Twitter-hosted meeting,
> since
> >>> those have traditionally been "Monthly on the first Thursday".
> After
> >>> this, the other meetings (third Thursday, or every other week?) can
> >>> alternate between 9pm/9am. Let's get these on the calendar
> officially.
> >>>
> >>> Vinod, are 

Updation

[Disha Singh]

Does the file:
/src/java/MESOS-MAVEN-README
need any updation.

I'm doubtful as it mentions mesos-0.19.0 even now.

Re: Install some 3rdparty packages needed for building Mesos modules

[Kapil Arya]

On Wed, Jan 27, 2016 at 8:04 AM, Alexander Rojas
 wrote:
> While valid, I feel that is a very un-unix way of doing this. There are a 
> couple of ideas from me here.
>
> 1. We should separate between a dev release and a normal release. The dev 
> release will include headers for people who want to build modules and other 
> mesos stuff, and the normal release only includes the executables.

The dev and normal releases are from the packaging point of view, when
someone installs pre-compiled Mesos binaries. Here we are talking
about users who run `./configure; make; make install`. For packaging,
I totally agree that we shouldn't bundle the 3rdparty stuff (and
distros won't let us do that anyways).

> 2. When building Mesos, we should avoid exporting unnecessary symbols. This 
> happens to me when building a framework which used a newer version of boost, 
> but when trying to link to mesos, it was taken boost symbols from Mesos, 
> rather annoying (I gave up at the end). I had this problem in the past but I 
> just cannot remember how it was solved.

True. The boost problem that you encountered is exactly the kind of
problem this effort is trying to address.
>
> With respect to Alex issue, I don’t see them as much of a problem as long as 
> we keep the standard behavior of the `--prefix` flag, which allows 
> installation of different versions in different directores.

Yup, we are not proposing to change any semantics of --prefix at all.

>
>
>> On 26 Jan 2016, at 19:54, Kapil Arya  wrote:
>>
>> Thanks for the feedback, Alex! I have inlined my responses.
>>
>>> First, I think we should support two use cases: installing 3rdparty
>>> packages and exposing them in the local build. As a Mesos (module)
>>> developer, I may have different versions of Mesos on my machine and I
>>> install neither of them to avoid conflicts. If I develop a module for a
>>> particular Mesos version (i.e. build), I would like to use artifacts of
>>> that build without installing them anywhere.
>>
>> That's a valid use case. How about "installing" the 3rdparty packages
>> by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
>> can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
>> "$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
>> modules? We can also update libprocess/Mesos to also use these
>> locations instead of passing a dozen "-I" and "-L" flags during
>> compilation. I am guessing this won't be too intrusive to the overall
>> build system.
>>
>>> Second, additionally 3rdparty packages, how about modules we provide with
>>> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
>>> refactor default implementations into modules (e.g. hierarchical
>>> allocator), we should install them somewhere.
>>
>> We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
>> for it :-). We should just install them in $(pkglibdir). That's the
>> default location for distro packaging as well. That's not too hard to
>> do. Just that we need to decide which modules should be installed.
>>
>> Best,
>> Kapil
>>
>>
>>> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya  wrote:
>>>
 On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio 
 wrote:
> Great thinking, Kapil!
> (I'm one who got the headache :)
>
> However, having recently gone through the effort of having to figure out
 it
> all, my +1 goes for *good documentation* of what is necessary.

 Totally with you on this :)


> When installing stuff / magic happening behind the scenes, it is always
> difficult to ensure it works on all "supported" platforms (and let's not
> even go into non-supported ones) and we would also run the risk that
 future
> changes may inadvertently break it.
>
> Bear also in mind that folks (who may not be using the --prefix) may be
> "surprised" to find incompatible/unexpected versions of
 glog/protobuf/etc.
> in the /usr/local system dir.

 This is the reason why we want to put it inside Mesos "owned"
 directories (e.g., /usr/local/include/mesos/3rdparty,
 /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
 free for other applications/packages installed on the system.

> We could also provide "exemplary scripts" that automate (most of) the
> tedious work and example build files, alongside documentation.
> If folks agree that this is a desirable alternative, I'm happy to help
 out
> - as mentioned, I've recently been through this, so memory is still
 fresh.

 I think several of us have developed such scripts by now. However, the
 problem is maintainability as they get out-of-sync whenever a 3rdparty
 component is updated in Mesos :-/.

>
> My 2c.
>
> --
> *Marco Massenzio*
> http://codetrips.com
>
> On Tue, Jan 19, 

[VOTE] Release Apache Mesos 0.27.0 (rc2)

[Michael Park]

Hi all,

Please vote on releasing the following candidate as Apache Mesos 0.27.0.

0.27.0 includes the following:

We added major features such as Implicit Roles, Quota, Multiple Disks and
more.

We also added major bug fixes such as performance improvements to
state.json requests and GLOG.

The CHANGELOG for the release is available at:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc2


The candidate for Mesos 0.27.0 release is available at:
https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz

The tag to be voted on is 0.27.0-rc2:
https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc2

The MD5 checksum of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.md5

The signature of the tarball can be found at:
https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc2/mesos-0.27.0.tar.gz.asc

The PGP key used to sign the release is here:
https://dist.apache.org/repos/dist/release/mesos/KEYS

The JAR is up in Maven in a staging repository here:
https://repository.apache.org/content/repositories/orgapachemesos-1100

Please vote on releasing this package as Apache Mesos 0.27.0!

The vote is open until Sat Jan 30 23:59:59 PST 2016 and passes if a
majority of at least 3 +1 PMC votes are cast.

[ ] +1 Release this package as Apache Mesos 0.27.0
[ ] -1 Do not release this package because ...

Thanks,

Tim, Kapil, MPark

Re: JIRA Shepherds

[Vaibhav Khanduja]

+1 on this …. it would be great to discuss this in weekly call ...

On Wed, Jan 27, 2016 at 4:17 AM, Christopher Hicks  wrote:

> Would it be easier to invite some of those seasoned contributors to be
> committers rather than creating a new tier of contributors?  Creating
> additional organization complexity seems unnecessary and potentially
> distracting unless there is some reason not to increase the core committer
> team count.
>
> On Wed, Jan 27, 2016 at 2:56 AM, Alexander Rojas 
> wrote:
>
> > My grain of sand here. It is true that committers are a scare resource
> and
> > it might be hard to get shepherds nowadays. However we do have a bunch of
> > seasoned contributors, which while not being committers are active and
> know
> > some of the innards of Mesos very well. How about having these guys as
> > shepherds?
> >
> > At the end a committer may be required to sign off a project, but all the
> > work of communicating with the contributor, come up with a design could
> be
> > lifter off from committers?
> >
> > What do you guys thing about the idea?
> >
> >
> > > On 27 Jan 2016, at 00:29, Vaibhav Khanduja 
> > wrote:
> > >
> > > The community is growing with more individuals getting interested in
> > > contributing to the project. This definitely brings an extra bit of
> > > workload for committers “Shepherds” but at the same time more
> developers
> > > eventually leads more adoptability across organization and enterprises.
> > >
> > >
> > >
> > > I am not sure if this is easy to find an immediate solution but would
> > > really like some sort of resolution on this. If shepherd is busy, what
> > else
> > > can be done for a low priority but a genuine issue.
> > >
> > > On Sun, Jan 24, 2016 at 4:12 PM, Joris Van Remoortere <
> > > joris.van.remoort...@gmail.com> wrote:
> > >
> > >> Hello Mesos developers,
> > >>
> > >> You may have noticed some churn in Jira recently around the shepherd
> > >> assignment. Specifically, we have unassigned the shepherds for a bunch
> > of
> > >> projects. We did this in order to get a better sense of which projects
> > are
> > >> being actively shepherded versus having gone stale, and to identify
> for
> > >> which projects we need to find a new shepherd who has sufficient time
> to
> > >> dedicate to it.
> > >>
> > >> This is not a statement that the un-assigned tickets are not
> important,
> > >> rather, we want to ensure that the people working on them have a
> > shepherd
> > >> with sufficient resources.
> > >>
> > >> We ask that you communicate (and agree!) with your shepherd before
> > >> assigning them in Jira, so that they are not surprised when you
> reviews
> > >> start getting posted.
> > >>
> > >> The benefit for the developer community should be that it will be more
> > >> clear when working on a ticket whether there are sufficient resources
> in
> > >> the community to iterate on it in a timely manner.
> > >>
> > >> Joris
> > >>
> >
> >
>
>
> --
> Christopher Hicks
> Uber SRE
> +1.757.598.2032
>

Re: Install some 3rdparty packages needed for building Mesos modules

[James Peach]

> On Jan 27, 2016, at 7:28 AM, Kapil Arya  wrote:
> 
> On Wed, Jan 27, 2016 at 8:04 AM, Alexander Rojas
>  wrote:
>> While valid, I feel that is a very un-unix way of doing this. There are a 
>> couple of ideas from me here.
>> 
>> 1. We should separate between a dev release and a normal release. The dev 
>> release will include headers for people who want to build modules and other 
>> mesos stuff, and the normal release only includes the executables.
> 
> The dev and normal releases are from the packaging point of view, when
> someone installs pre-compiled Mesos binaries. Here we are talking
> about users who run `./configure; make; make install`. For packaging,
> I totally agree that we shouldn't bundle the 3rdparty stuff (and
> distros won't let us do that anyways).

FWIW I don't know that it is possible to build Mesos without bundled 3rdparty. 
Fedora 23 has glog, gtest and gmock packages, but I wasn't able to get the 
build to digest them. AFAICT it is partly a packaging problem and partly a 
Mesos build problem.

> 
>> 2. When building Mesos, we should avoid exporting unnecessary symbols. This 
>> happens to me when building a framework which used a newer version of boost, 
>> but when trying to link to mesos, it was taken boost symbols from Mesos, 
>> rather annoying (I gave up at the end). I had this problem in the past but I 
>> just cannot remember how it was solved.
> 
> True. The boost problem that you encountered is exactly the kind of
> problem this effort is trying to address.
>> 
>> With respect to Alex issue, I don’t see them as much of a problem as long as 
>> we keep the standard behavior of the `--prefix` flag, which allows 
>> installation of different versions in different directores.
> 
> Yup, we are not proposing to change any semantics of --prefix at all.
> 
>> 
>> 
>>> On 26 Jan 2016, at 19:54, Kapil Arya  wrote:
>>> 
>>> Thanks for the feedback, Alex! I have inlined my responses.
>>> 
 First, I think we should support two use cases: installing 3rdparty
 packages and exposing them in the local build. As a Mesos (module)
 developer, I may have different versions of Mesos on my machine and I
 install neither of them to avoid conflicts. If I develop a module for a
 particular Mesos version (i.e. build), I would like to use artifacts of
 that build without installing them anywhere.
>>> 
>>> That's a valid use case. How about "installing" the 3rdparty packages
>>> by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
>>> can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
>>> "$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
>>> modules? We can also update libprocess/Mesos to also use these
>>> locations instead of passing a dozen "-I" and "-L" flags during
>>> compilation. I am guessing this won't be too intrusive to the overall
>>> build system.
>>> 
 Second, additionally 3rdparty packages, how about modules we provide with
 Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
 refactor default implementations into modules (e.g. hierarchical
 allocator), we should install them somewhere.
>>> 
>>> We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
>>> for it :-). We should just install them in $(pkglibdir). That's the
>>> default location for distro packaging as well. That's not too hard to
>>> do. Just that we need to decide which modules should be installed.
>>> 
>>> Best,
>>> Kapil
>>> 
>>> 
 On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya  wrote:
 
> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio 
> wrote:
>> Great thinking, Kapil!
>> (I'm one who got the headache :)
>> 
>> However, having recently gone through the effort of having to figure out
> it
>> all, my +1 goes for *good documentation* of what is necessary.
> 
> Totally with you on this :)
> 
> 
>> When installing stuff / magic happening behind the scenes, it is always
>> difficult to ensure it works on all "supported" platforms (and let's not
>> even go into non-supported ones) and we would also run the risk that
> future
>> changes may inadvertently break it.
>> 
>> Bear also in mind that folks (who may not be using the --prefix) may be
>> "surprised" to find incompatible/unexpected versions of
> glog/protobuf/etc.
>> in the /usr/local system dir.
> 
> This is the reason why we want to put it inside Mesos "owned"
> directories (e.g., /usr/local/include/mesos/3rdparty,
> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
> free for other applications/packages installed on the system.
> 
>> We could also provide "exemplary scripts" that automate (most of) the
>> tedious work and example build files, alongside documentation.
>> If folks agree 

Re: JIRA Shepherds

[Timothy Chen]

Yes the intention is to make the seasoned contributors (really all
contributors!) committers, and we are definitely trying to make that
happen with actively being mentored and contribution over time.

Also encourage anyone interested in becoming committers with Mesos to
look at the Bernd's committer checklist:

https://mail-archives.apache.org/mod_mbox/mesos-dev/201505.mbox/%3ccaakwvazmvr5nxz5ios3uohcx41yv9n73jh_gcrmnnaiekh8...@mail.gmail.com%3E

Please also reach out on the dev list or to us on IRC if you have more
questions or like to understand more what concrete steps required for
them.

Tim


On Wed, Jan 27, 2016 at 11:16 AM, Vaibhav Khanduja
 wrote:
> +1 on this …. it would be great to discuss this in weekly call ...
>
> On Wed, Jan 27, 2016 at 4:17 AM, Christopher Hicks  wrote:
>
>> Would it be easier to invite some of those seasoned contributors to be
>> committers rather than creating a new tier of contributors?  Creating
>> additional organization complexity seems unnecessary and potentially
>> distracting unless there is some reason not to increase the core committer
>> team count.
>>
>> On Wed, Jan 27, 2016 at 2:56 AM, Alexander Rojas 
>> wrote:
>>
>> > My grain of sand here. It is true that committers are a scare resource
>> and
>> > it might be hard to get shepherds nowadays. However we do have a bunch of
>> > seasoned contributors, which while not being committers are active and
>> know
>> > some of the innards of Mesos very well. How about having these guys as
>> > shepherds?
>> >
>> > At the end a committer may be required to sign off a project, but all the
>> > work of communicating with the contributor, come up with a design could
>> be
>> > lifter off from committers?
>> >
>> > What do you guys thing about the idea?
>> >
>> >
>> > > On 27 Jan 2016, at 00:29, Vaibhav Khanduja 
>> > wrote:
>> > >
>> > > The community is growing with more individuals getting interested in
>> > > contributing to the project. This definitely brings an extra bit of
>> > > workload for committers “Shepherds” but at the same time more
>> developers
>> > > eventually leads more adoptability across organization and enterprises.
>> > >
>> > >
>> > >
>> > > I am not sure if this is easy to find an immediate solution but would
>> > > really like some sort of resolution on this. If shepherd is busy, what
>> > else
>> > > can be done for a low priority but a genuine issue.
>> > >
>> > > On Sun, Jan 24, 2016 at 4:12 PM, Joris Van Remoortere <
>> > > joris.van.remoort...@gmail.com> wrote:
>> > >
>> > >> Hello Mesos developers,
>> > >>
>> > >> You may have noticed some churn in Jira recently around the shepherd
>> > >> assignment. Specifically, we have unassigned the shepherds for a bunch
>> > of
>> > >> projects. We did this in order to get a better sense of which projects
>> > are
>> > >> being actively shepherded versus having gone stale, and to identify
>> for
>> > >> which projects we need to find a new shepherd who has sufficient time
>> to
>> > >> dedicate to it.
>> > >>
>> > >> This is not a statement that the un-assigned tickets are not
>> important,
>> > >> rather, we want to ensure that the people working on them have a
>> > shepherd
>> > >> with sufficient resources.
>> > >>
>> > >> We ask that you communicate (and agree!) with your shepherd before
>> > >> assigning them in Jira, so that they are not surprised when you
>> reviews
>> > >> start getting posted.
>> > >>
>> > >> The benefit for the developer community should be that it will be more
>> > >> clear when working on a ticket whether there are sufficient resources
>> in
>> > >> the community to iterate on it in a timely manner.
>> > >>
>> > >> Joris
>> > >>
>> >
>> >
>>
>>
>> --
>> Christopher Hicks
>> Uber SRE
>> +1.757.598.2032
>>

Re: [VOTE] Release Apache Mesos 0.27.0 (rc1)

[Joris Van Remoortere]

-1 (binding)
There is a bug with mutable resource math that surfaced in the allocator
changes, but is also happening elsehwere.
Mpark is currently working on a patch to disallow this behavior in general,
and fix the current issues.

https://issues.apache.org/jira/browse/MESOS-4030


On Wed, Jan 27, 2016 at 6:51 AM, Alexander Rojas 
wrote:

> -1 (non binding)
>
> Test on Debian 8 under a VirtualBox debian machine. While doing
>
> `configure && sudo make -j4 check`
>
> and then:
>
> `sudo ./bin/mesos-tests.sh
> --gtest_filter=“-*.ROOT_CGROUPS_Listen:*.ROOT_IncreaseRSS"
> --gtest_repeat=10 --gtest_break_on_failure`
>
> I got failures on DockerContainerizerTest.ROOT_DOCKER_NC_PortMapping and
> NetClsIsolatorTest.ROOT_CGROUPS_NetClsIsolate.
>
> The first had a JIRA entry but was marked as resolved in 0.26.0 with a
> cannot reproduce. The second didn’t have any issues open.
>
> My -1 vote will stand until the failing tests are decidedly non blockers
> for the release.
>
> > On 27 Jan 2016, at 07:53, Timothy Chen  wrote:
> >
> > Hi all,
> >
> > Please vote on releasing the following candidate as Apache Mesos 0.27.0.
> >
> > 0.27.0 includes the following:
> >
> 
> > We added major features such as Implicit Roles, Quota, Multiple Disks
> and more.
> >
> > We also added major bug fixes such as performance improvements to
> > state.json requests and GLOG.
> >
> > The CHANGELOG for the release is available at:
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc1
> >
> 
> >
> > The candidate for Mesos 0.27.0 release is available at:
> >
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz
> >
> > The tag to be voted on is 0.27.0-rc1:
> >
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc1
> >
> > The MD5 checksum of the tarball can be found at:
> >
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.md5
> >
> > The signature of the tarball can be found at:
> >
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.asc
> >
> > The PGP key used to sign the release is here:
> > https://dist.apache.org/repos/dist/release/mesos/KEYS
> >
> > The JAR is up in Maven in a staging repository here:
> > https://repository.apache.org/content/repositories/orgapachemesos-1097
> >
> > Please vote on releasing this package as Apache Mesos 0.27.0!
> >
> > The vote is open until Fri Jan 29 23:59:59 PST 2016 and passes if a
> > majority of at least 3 +1 PMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Mesos 0.27.0
> > [ ] -1 Do not release this package because ...
> >
> > Thanks,
> >
> > Tim, MPark and Kapil
>
>

Re: [VOTE] Release Apache Mesos 0.27.0 (rc1)

[Joris Van Remoortere]

Correction to my previous e-mail.
The mutable resource bug is here:
https://issues.apache.org/jira/browse/MESOS-4534

On Wed, Jan 27, 2016 at 11:57 AM, Joris Van Remoortere <
joris.van.remoort...@gmail.com> wrote:

> -1 (binding)
> There is a bug with mutable resource math that surfaced in the allocator
> changes, but is also happening elsehwere.
> Mpark is currently working on a patch to disallow this behavior in
> general, and fix the current issues.
>
> https://issues.apache.org/jira/browse/MESOS-4030
>
>
> On Wed, Jan 27, 2016 at 6:51 AM, Alexander Rojas 
> wrote:
>
>> -1 (non binding)
>>
>> Test on Debian 8 under a VirtualBox debian machine. While doing
>>
>> `configure && sudo make -j4 check`
>>
>> and then:
>>
>> `sudo ./bin/mesos-tests.sh
>> --gtest_filter=“-*.ROOT_CGROUPS_Listen:*.ROOT_IncreaseRSS"
>> --gtest_repeat=10 --gtest_break_on_failure`
>>
>> I got failures on DockerContainerizerTest.ROOT_DOCKER_NC_PortMapping and
>> NetClsIsolatorTest.ROOT_CGROUPS_NetClsIsolate.
>>
>> The first had a JIRA entry but was marked as resolved in 0.26.0 with a
>> cannot reproduce. The second didn’t have any issues open.
>>
>> My -1 vote will stand until the failing tests are decidedly non blockers
>> for the release.
>>
>> > On 27 Jan 2016, at 07:53, Timothy Chen  wrote:
>> >
>> > Hi all,
>> >
>> > Please vote on releasing the following candidate as Apache Mesos 0.27.0.
>> >
>> > 0.27.0 includes the following:
>> >
>> 
>> > We added major features such as Implicit Roles, Quota, Multiple Disks
>> and more.
>> >
>> > We also added major bug fixes such as performance improvements to
>> > state.json requests and GLOG.
>> >
>> > The CHANGELOG for the release is available at:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc1
>> >
>> 
>> >
>> > The candidate for Mesos 0.27.0 release is available at:
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz
>> >
>> > The tag to be voted on is 0.27.0-rc1:
>> >
>> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc1
>> >
>> > The MD5 checksum of the tarball can be found at:
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.md5
>> >
>> > The signature of the tarball can be found at:
>> >
>> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.asc
>> >
>> > The PGP key used to sign the release is here:
>> > https://dist.apache.org/repos/dist/release/mesos/KEYS
>> >
>> > The JAR is up in Maven in a staging repository here:
>> > https://repository.apache.org/content/repositories/orgapachemesos-1097
>> >
>> > Please vote on releasing this package as Apache Mesos 0.27.0!
>> >
>> > The vote is open until Fri Jan 29 23:59:59 PST 2016 and passes if a
>> > majority of at least 3 +1 PMC votes are cast.
>> >
>> > [ ] +1 Release this package as Apache Mesos 0.27.0
>> > [ ] -1 Do not release this package because ...
>> >
>> > Thanks,
>> >
>> > Tim, MPark and Kapil
>>
>>
>

Re: JIRA Shepherds

[Christopher Hicks]

Would it be easier to invite some of those seasoned contributors to be
committers rather than creating a new tier of contributors?  Creating
additional organization complexity seems unnecessary and potentially
distracting unless there is some reason not to increase the core committer
team count.

On Wed, Jan 27, 2016 at 2:56 AM, Alexander Rojas 
wrote:

> My grain of sand here. It is true that committers are a scare resource and
> it might be hard to get shepherds nowadays. However we do have a bunch of
> seasoned contributors, which while not being committers are active and know
> some of the innards of Mesos very well. How about having these guys as
> shepherds?
>
> At the end a committer may be required to sign off a project, but all the
> work of communicating with the contributor, come up with a design could be
> lifter off from committers?
>
> What do you guys thing about the idea?
>
>
> > On 27 Jan 2016, at 00:29, Vaibhav Khanduja 
> wrote:
> >
> > The community is growing with more individuals getting interested in
> > contributing to the project. This definitely brings an extra bit of
> > workload for committers “Shepherds” but at the same time more developers
> > eventually leads more adoptability across organization and enterprises.
> >
> >
> >
> > I am not sure if this is easy to find an immediate solution but would
> > really like some sort of resolution on this. If shepherd is busy, what
> else
> > can be done for a low priority but a genuine issue.
> >
> > On Sun, Jan 24, 2016 at 4:12 PM, Joris Van Remoortere <
> > joris.van.remoort...@gmail.com> wrote:
> >
> >> Hello Mesos developers,
> >>
> >> You may have noticed some churn in Jira recently around the shepherd
> >> assignment. Specifically, we have unassigned the shepherds for a bunch
> of
> >> projects. We did this in order to get a better sense of which projects
> are
> >> being actively shepherded versus having gone stale, and to identify for
> >> which projects we need to find a new shepherd who has sufficient time to
> >> dedicate to it.
> >>
> >> This is not a statement that the un-assigned tickets are not important,
> >> rather, we want to ensure that the people working on them have a
> shepherd
> >> with sufficient resources.
> >>
> >> We ask that you communicate (and agree!) with your shepherd before
> >> assigning them in Jira, so that they are not surprised when you reviews
> >> start getting posted.
> >>
> >> The benefit for the developer community should be that it will be more
> >> clear when working on a ticket whether there are sufficient resources in
> >> the community to iterate on it in a timely manner.
> >>
> >> Joris
> >>
>
>


-- 
Christopher Hicks
Uber SRE
+1.757.598.2032

Re: JIRA Shepherds

[Alexander Rojas]

My grain of sand here. It is true that committers are a scare resource and it 
might be hard to get shepherds nowadays. However we do have a bunch of seasoned 
contributors, which while not being committers are active and know some of the 
innards of Mesos very well. How about having these guys as shepherds?

At the end a committer may be required to sign off a project, but all the work 
of communicating with the contributor, come up with a design could be lifter 
off from committers?

What do you guys thing about the idea?


> On 27 Jan 2016, at 00:29, Vaibhav Khanduja  wrote:
> 
> The community is growing with more individuals getting interested in
> contributing to the project. This definitely brings an extra bit of
> workload for committers “Shepherds” but at the same time more developers
> eventually leads more adoptability across organization and enterprises.
> 
> 
> 
> I am not sure if this is easy to find an immediate solution but would
> really like some sort of resolution on this. If shepherd is busy, what else
> can be done for a low priority but a genuine issue.
> 
> On Sun, Jan 24, 2016 at 4:12 PM, Joris Van Remoortere <
> joris.van.remoort...@gmail.com> wrote:
> 
>> Hello Mesos developers,
>> 
>> You may have noticed some churn in Jira recently around the shepherd
>> assignment. Specifically, we have unassigned the shepherds for a bunch of
>> projects. We did this in order to get a better sense of which projects are
>> being actively shepherded versus having gone stale, and to identify for
>> which projects we need to find a new shepherd who has sufficient time to
>> dedicate to it.
>> 
>> This is not a statement that the un-assigned tickets are not important,
>> rather, we want to ensure that the people working on them have a shepherd
>> with sufficient resources.
>> 
>> We ask that you communicate (and agree!) with your shepherd before
>> assigning them in Jira, so that they are not surprised when you reviews
>> start getting posted.
>> 
>> The benefit for the developer community should be that it will be more
>> clear when working on a ticket whether there are sufficient resources in
>> the community to iterate on it in a timely manner.
>> 
>> Joris
>> 

Re: Contribution Request

[Artem Harutyunyan]

Done. Welcome to Mesos and sorry this fell through the cracks.

Artem.

On Wed, Jan 20, 2016 at 7:09 PM, Jayamohan.K  wrote:
> Pl add me as a Mesos Contributor.
>
> My Apache Review Board and Jira username is jayamohank
>
> Thanks
> JayK

Re: [VOTE] Release Apache Mesos 0.27.0 (rc1)

[Alexander Rojas]

-1 (non binding)

Test on Debian 8 under a VirtualBox debian machine. While doing

`configure && sudo make -j4 check`

and then:

`sudo ./bin/mesos-tests.sh 
--gtest_filter=“-*.ROOT_CGROUPS_Listen:*.ROOT_IncreaseRSS" --gtest_repeat=10 
--gtest_break_on_failure`

I got failures on DockerContainerizerTest.ROOT_DOCKER_NC_PortMapping and 
NetClsIsolatorTest.ROOT_CGROUPS_NetClsIsolate.

The first had a JIRA entry but was marked as resolved in 0.26.0 with a cannot 
reproduce. The second didn’t have any issues open.

My -1 vote will stand until the failing tests are decidedly non blockers for 
the release.

> On 27 Jan 2016, at 07:53, Timothy Chen  wrote:
> 
> Hi all,
> 
> Please vote on releasing the following candidate as Apache Mesos 0.27.0.
> 
> 0.27.0 includes the following:
> 
> We added major features such as Implicit Roles, Quota, Multiple Disks and 
> more.
> 
> We also added major bug fixes such as performance improvements to
> state.json requests and GLOG.
> 
> The CHANGELOG for the release is available at:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=blob_plain;f=CHANGELOG;hb=0.27.0-rc1
> 
> 
> The candidate for Mesos 0.27.0 release is available at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz
> 
> The tag to be voted on is 0.27.0-rc1:
> https://git-wip-us.apache.org/repos/asf?p=mesos.git;a=commit;h=0.27.0-rc1
> 
> The MD5 checksum of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.md5
> 
> The signature of the tarball can be found at:
> https://dist.apache.org/repos/dist/dev/mesos/0.27.0-rc1/mesos-0.27.0.tar.gz.asc
> 
> The PGP key used to sign the release is here:
> https://dist.apache.org/repos/dist/release/mesos/KEYS
> 
> The JAR is up in Maven in a staging repository here:
> https://repository.apache.org/content/repositories/orgapachemesos-1097
> 
> Please vote on releasing this package as Apache Mesos 0.27.0!
> 
> The vote is open until Fri Jan 29 23:59:59 PST 2016 and passes if a
> majority of at least 3 +1 PMC votes are cast.
> 
> [ ] +1 Release this package as Apache Mesos 0.27.0
> [ ] -1 Do not release this package because ...
> 
> Thanks,
> 
> Tim, MPark and Kapil

Re: Install some 3rdparty packages needed for building Mesos modules

[Alexander Rojas]

While valid, I feel that is a very un-unix way of doing this. There are a 
couple of ideas from me here.

1. We should separate between a dev release and a normal release. The dev 
release will include headers for people who want to build modules and other 
mesos stuff, and the normal release only includes the executables.
2. When building Mesos, we should avoid exporting unnecessary symbols. This 
happens to me when building a framework which used a newer version of boost, 
but when trying to link to mesos, it was taken boost symbols from Mesos, rather 
annoying (I gave up at the end). I had this problem in the past but I just 
cannot remember how it was solved.

With respect to Alex issue, I don’t see them as much of a problem as long as we 
keep the standard behavior of the `--prefix` flag, which allows installation of 
different versions in different directores.


> On 26 Jan 2016, at 19:54, Kapil Arya  wrote:
> 
> Thanks for the feedback, Alex! I have inlined my responses.
> 
>> First, I think we should support two use cases: installing 3rdparty
>> packages and exposing them in the local build. As a Mesos (module)
>> developer, I may have different versions of Mesos on my machine and I
>> install neither of them to avoid conflicts. If I develop a module for a
>> particular Mesos version (i.e. build), I would like to use artifacts of
>> that build without installing them anywhere.
> 
> That's a valid use case. How about "installing" the 3rdparty packages
> by setting their $PREFIX to $(top_builddir)/3rdparty? That way, one
> can append "-I$(top_builddir)/3rdparty/include" to CPPFLAGS and
> "$(top_builddir)/3rdparty/lib" to their LD_LIBRARY_PATH when building
> modules? We can also update libprocess/Mesos to also use these
> locations instead of passing a dozen "-I" and "-L" flags during
> compilation. I am guessing this won't be too intrusive to the overall
> build system.
> 
>> Second, additionally 3rdparty packages, how about modules we provide with
>> Mesos, e.g. FixedResourceEstimator? Also if in the future we decide to
>> refactor default implementations into modules (e.g. hierarchical
>> allocator), we should install them somewhere.
> 
> We have a ticket (https://issues.apache.org/jira/browse/MESOS-1940)
> for it :-). We should just install them in $(pkglibdir). That's the
> default location for distro packaging as well. That's not too hard to
> do. Just that we need to decide which modules should be installed.
> 
> Best,
> Kapil
> 
> 
>> On Wed, Jan 20, 2016 at 8:09 AM, Kapil Arya  wrote:
>> 
>>> On Wed, Jan 20, 2016 at 2:04 AM, Marco Massenzio 
>>> wrote:
 Great thinking, Kapil!
 (I'm one who got the headache :)
 
 However, having recently gone through the effort of having to figure out
>>> it
 all, my +1 goes for *good documentation* of what is necessary.
>>> 
>>> Totally with you on this :)
>>> 
>>> 
 When installing stuff / magic happening behind the scenes, it is always
 difficult to ensure it works on all "supported" platforms (and let's not
 even go into non-supported ones) and we would also run the risk that
>>> future
 changes may inadvertently break it.
 
 Bear also in mind that folks (who may not be using the --prefix) may be
 "surprised" to find incompatible/unexpected versions of
>>> glog/protobuf/etc.
 in the /usr/local system dir.
>>> 
>>> This is the reason why we want to put it inside Mesos "owned"
>>> directories (e.g., /usr/local/include/mesos/3rdparty,
>>> /usr/lib64/mesos/3rdparty) so that this whole operation is side-effect
>>> free for other applications/packages installed on the system.
>>> 
 We could also provide "exemplary scripts" that automate (most of) the
 tedious work and example build files, alongside documentation.
 If folks agree that this is a desirable alternative, I'm happy to help
>>> out
 - as mentioned, I've recently been through this, so memory is still
>>> fresh.
>>> 
>>> I think several of us have developed such scripts by now. However, the
>>> problem is maintainability as they get out-of-sync whenever a 3rdparty
>>> component is updated in Mesos :-/.
>>> 
 
 My 2c.
 
 --
 *Marco Massenzio*
 http://codetrips.com
 
 On Tue, Jan 19, 2016 at 10:22 PM, Kapil Arya 
>>> wrote:
 
> On Tue, Jan 19, 2016 at 11:58 PM, James Peach  wrote:
>> 
>>> On Jan 19, 2016, at 2:03 PM, Kapil Arya  wrote:
>>> 
>>> Hi All,
>>> 
>>> I wanted to get your opinion on installing the 3rdparty packages
>>> glog,
>>> protobuf, boost and picojson[1] when installing Mesos itself. These
>>> packages are required to build Mesos modules.
>> 
>> An alternative approach could be to hide these headers so they are
> internal to Mesos and not incidentally required by innocent modules.
>>> IIRC
> this should be fairly