Welcome Kapil as Mesos committer and PMC member!

[Till Toenshoff]

I'm happy to announce that Kapil Arya has been voted a Mesos committer and PMC 
member!

Welcome Kapil, and thanks for all of your great contributions to the project so 
far! 

Looking forward to lots more of your contributions!

Thanks
Till

Re: Welcome Kapil as Mesos committer and PMC member!

[haosdent]

Congratulations!

On Thu, Nov 5, 2015 at 6:02 PM, Till Toenshoff  wrote:

> I'm happy to announce that Kapil Arya has been voted a Mesos committer and
> PMC member!
>
> Welcome Kapil, and thanks for all of your great contributions to the
> project so far!
>
> Looking forward to lots more of your contributions!
>
> Thanks
> Till




-- 
Best Regards,
Haosdent Huang

Re: Proposal: move towards #pragma and away from #include guards

[haosdent]

+1

On Thu, Nov 5, 2015 at 7:58 PM, Bernd Mathiske  wrote:

> +1
>
> This site has a list of compilers that support #pragma once.
>
> https://en.wikipedia.org/wiki/Pragma_once#Portability
>
> Clang, MS V C++, GCC as of 3.4. from 2006. OK!
>
> (Too bad for Sun/Oracle Studio C++. But you can use GCC on Solaris, right?)
>
> We could tackle this change at the same time as correcting the copyright
> notes, then we have the history clutter only once:
>
> https://issues.apache.org/jira/browse/MESOS-3581
>
> Any other projects of that nature that can be bundled?
>
> Bernd
>
> On Nov 5, 2015, at 6:36 AM, Alex Clemmer 
> wrote:
>
> Hey folks.
>
> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> brought up the issue of moving away from #include guards and towards
> `#pragma once`.
>
> As this has been brought up before, I will be brief: we think it's
> revisiting because the primary objection in previous threads appears
> to be that, though `#pragma once` is a cleaner solution to the
> multiple-include problem, it's not so much better that it's worth the
> code churn. However, the ongoing Windows integration work means we
> have to touch these files anyway, so if we agree this is cleaner and
> desirable, then this is an opportunity to obtain that additional code
> clarity, without the cost of the churn.
>
> For the remainder of the email, I will summarize the history of our
> discussion of this issue, who will do the work, and what the next
> steps are.
>
> PROPOSAL: We propose that all new code use `#pragma once` instead of
> #include guards; for existing files, we propose that you change
> #include guards when you touch them.
>
> HISTORY: This has been discussed before, most recently a year ago on
> the mailing list[2]. There is a relevant JIRA[3] and discarded
> review[4] that changes style guide's recommendation on the matter.
>
> SUMMARIZED OBJECTIONS:
> 1. The Google style guide explicitly forbids `#pragma once`.
> 2. This results in a lot of code churn, but is only marginally better.
> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> doesn't support it.
> 4. Popular projects like Chrome don't do `#pragma once` because of
> history clutter.
> 5. Intermediate state of inconsistency as we transition to `#pragma
> once` from #include guards.
>
> OUR RESPONSE:
> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> points out in a previous thread that the Google style guide was
> canonized when `#pragma once` was Windows-only, and the guidance has
> not changed since because of the history churn problem. As noted
> above, we think the history churn problem is minimized by the fact
> that it can be wrapped up into the Windows integration work.
>
> For objection (3), the consensus seems to be that the vast majority of
> compilers we care about (in particular, the ones supporting C++ 11) do
> support it.
>
> For objection (5) we believe the inconsistent state is likely to not
> be long lived, as long as we commit to wrapping this work up into the
> Windows integration work.
>
> SUMMARIZED ADVANTAGES:
> * Basically fool-proof. Communicates simply what its function is (you
> include this file once). Semantically it is "the right tool for the
> job".
> * No need for namespacing conventions for #include guards.
> * No conflicts with reserved identifiers[5].
> * No internal conflicts between include guards in Stout, Process
> library, and Mesos (this is one reason we need the namespacing
> conventions)
> * Reduces preprocessor definition clutter (we should rely on #define
> as little as humanly possible).
> * Optimized to be easy to read and reason about.
>
> NEXT STEPS:
> If we agree that this is the right thing to do, committers would ask
> people to use `#pragma once` for new code when presented in code
> reviews. For files that exist, I will take point on transitioning as
> we complete the Windows integration work. I expect this work to
> completely land before the new year.
>
>
> Thanks,
>
>
> [1] https://reviews.apache.org/r/39803/
> [2] https://www.marc.info/?t=142540100400015=1=2
> [3] https://issues.apache.org/jira/browse/MESOS-2211
> [4] https://reviews.apache.org/r/30100/
> [5]
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
>
>
> --
> Alex
>
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)
>
>
>


-- 
Best Regards,
Haosdent Huang

Re: Proposal: move towards #pragma and away from #include guards

[Alex Rukletsov]

+1 for #pragma and +1 for Bernd's suggestion.

I normally don't like mass updates because they make it harder to read the
commit history. However in this case all the changes will be located at the
top of the file and shouldn't influence readability of the history.

However, I would limit the scope of this update to the aforementioned
changes only. IMO, including something else, e.g. s/> >/>>/, will do more
harm than good.


On Thu, Nov 5, 2015 at 3:21 PM, haosdent  wrote:

> +1
>
> On Thu, Nov 5, 2015 at 7:58 PM, Bernd Mathiske 
> wrote:
>
> > +1
> >
> > This site has a list of compilers that support #pragma once.
> >
> > https://en.wikipedia.org/wiki/Pragma_once#Portability
> >
> > Clang, MS V C++, GCC as of 3.4. from 2006. OK!
> >
> > (Too bad for Sun/Oracle Studio C++. But you can use GCC on Solaris,
> right?)
> >
> > We could tackle this change at the same time as correcting the copyright
> > notes, then we have the history clutter only once:
> >
> > https://issues.apache.org/jira/browse/MESOS-3581
> >
> > Any other projects of that nature that can be bundled?
> >
> > Bernd
> >
> > On Nov 5, 2015, at 6:36 AM, Alex Clemmer 
> > wrote:
> >
> > Hey folks.
> >
> > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > brought up the issue of moving away from #include guards and towards
> > `#pragma once`.
> >
> > As this has been brought up before, I will be brief: we think it's
> > revisiting because the primary objection in previous threads appears
> > to be that, though `#pragma once` is a cleaner solution to the
> > multiple-include problem, it's not so much better that it's worth the
> > code churn. However, the ongoing Windows integration work means we
> > have to touch these files anyway, so if we agree this is cleaner and
> > desirable, then this is an opportunity to obtain that additional code
> > clarity, without the cost of the churn.
> >
> > For the remainder of the email, I will summarize the history of our
> > discussion of this issue, who will do the work, and what the next
> > steps are.
> >
> > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > #include guards; for existing files, we propose that you change
> > #include guards when you touch them.
> >
> > HISTORY: This has been discussed before, most recently a year ago on
> > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > review[4] that changes style guide's recommendation on the matter.
> >
> > SUMMARIZED OBJECTIONS:
> > 1. The Google style guide explicitly forbids `#pragma once`.
> > 2. This results in a lot of code churn, but is only marginally better.
> > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > doesn't support it.
> > 4. Popular projects like Chrome don't do `#pragma once` because of
> > history clutter.
> > 5. Intermediate state of inconsistency as we transition to `#pragma
> > once` from #include guards.
> >
> > OUR RESPONSE:
> > Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> > points out in a previous thread that the Google style guide was
> > canonized when `#pragma once` was Windows-only, and the guidance has
> > not changed since because of the history churn problem. As noted
> > above, we think the history churn problem is minimized by the fact
> > that it can be wrapped up into the Windows integration work.
> >
> > For objection (3), the consensus seems to be that the vast majority of
> > compilers we care about (in particular, the ones supporting C++ 11) do
> > support it.
> >
> > For objection (5) we believe the inconsistent state is likely to not
> > be long lived, as long as we commit to wrapping this work up into the
> > Windows integration work.
> >
> > SUMMARIZED ADVANTAGES:
> > * Basically fool-proof. Communicates simply what its function is (you
> > include this file once). Semantically it is "the right tool for the
> > job".
> > * No need for namespacing conventions for #include guards.
> > * No conflicts with reserved identifiers[5].
> > * No internal conflicts between include guards in Stout, Process
> > library, and Mesos (this is one reason we need the namespacing
> > conventions)
> > * Reduces preprocessor definition clutter (we should rely on #define
> > as little as humanly possible).
> > * Optimized to be easy to read and reason about.
> >
> > NEXT STEPS:
> > If we agree that this is the right thing to do, committers would ask
> > people to use `#pragma once` for new code when presented in code
> > reviews. For files that exist, I will take point on transitioning as
> > we complete the Windows integration work. I expect this work to
> > completely land before the new year.
> >
> >
> > Thanks,
> >
> >
> > [1] https://reviews.apache.org/r/39803/
> > [2] https://www.marc.info/?t=142540100400015=1=2
> > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > [4] https://reviews.apache.org/r/30100/
> > [5]
> >
> 

Re: Welcome Kapil as Mesos committer and PMC member!

[Adam Bordelon]

Welcome, Kapil! Well-deserved.

On Thu, Nov 5, 2015 at 2:07 AM, haosdent  wrote:

> Congratulations!
>
> On Thu, Nov 5, 2015 at 6:02 PM, Till Toenshoff  wrote:
>
>> I'm happy to announce that Kapil Arya has been voted a Mesos committer
>> and PMC member!
>>
>> Welcome Kapil, and thanks for all of your great contributions to the
>> project so far!
>>
>> Looking forward to lots more of your contributions!
>>
>> Thanks
>> Till
>
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: Proposal: move towards #pragma and away from #include guards

[Alex Clemmer]

Just because I apparently was not very clear: in the "history" and
"summarized objections" sections of my original mail, I did attempt to
capture all of the objections from this thread and previous
discussions I found (and, just for the sake of thoroughness, I do
actually explicitly cite this thread in the footnotes). If you don't
want to dig through the thread yourself, I hope that this will give
you a good approximation of what happened in that thread.

I see now that I did fail to mention that this thread ended in
nonconsensus rather than an explicit decision against. Sorry about
that. You can also see evidence that the decision was nonconsensus
directly in the JIRA issues and the review I cite -- for example on
JIRA, Alex R mentions removing the newbie tag from the issue because
there is nonconsensus, and the review was discarded, with the cited
reason being nonconsensus.

Hopefully this clarifies these issues.

On Thu, Nov 5, 2015 at 8:32 AM, Alexander Rojas  wrote:
> While I’m all in on the proposal, we did have this discussion almost a year 
> ago [1] at the end I think, the decision was not to use them, though I don’t 
> remember the exact reason. In any case, I vote +1 non-binding.
>
> [1] 
> http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E
>  
> 
>
>
>> On 05 Nov 2015, at 06:36, Alex Clemmer  wrote:
>>
>> Hey folks.
>>
>> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
>> brought up the issue of moving away from #include guards and towards
>> `#pragma once`.
>>
>> As this has been brought up before, I will be brief: we think it's
>> revisiting because the primary objection in previous threads appears
>> to be that, though `#pragma once` is a cleaner solution to the
>> multiple-include problem, it's not so much better that it's worth the
>> code churn. However, the ongoing Windows integration work means we
>> have to touch these files anyway, so if we agree this is cleaner and
>> desirable, then this is an opportunity to obtain that additional code
>> clarity, without the cost of the churn.
>>
>> For the remainder of the email, I will summarize the history of our
>> discussion of this issue, who will do the work, and what the next
>> steps are.
>>
>> PROPOSAL: We propose that all new code use `#pragma once` instead of
>> #include guards; for existing files, we propose that you change
>> #include guards when you touch them.
>>
>> HISTORY: This has been discussed before, most recently a year ago on
>> the mailing list[2]. There is a relevant JIRA[3] and discarded
>> review[4] that changes style guide's recommendation on the matter.
>>
>> SUMMARIZED OBJECTIONS:
>> 1. The Google style guide explicitly forbids `#pragma once`.
>> 2. This results in a lot of code churn, but is only marginally better.
>> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
>> doesn't support it.
>> 4. Popular projects like Chrome don't do `#pragma once` because of
>> history clutter.
>> 5. Intermediate state of inconsistency as we transition to `#pragma
>> once` from #include guards.
>>
>> OUR RESPONSE:
>> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
>> points out in a previous thread that the Google style guide was
>> canonized when `#pragma once` was Windows-only, and the guidance has
>> not changed since because of the history churn problem. As noted
>> above, we think the history churn problem is minimized by the fact
>> that it can be wrapped up into the Windows integration work.
>>
>> For objection (3), the consensus seems to be that the vast majority of
>> compilers we care about (in particular, the ones supporting C++ 11) do
>> support it.
>>
>> For objection (5) we believe the inconsistent state is likely to not
>> be long lived, as long as we commit to wrapping this work up into the
>> Windows integration work.
>>
>> SUMMARIZED ADVANTAGES:
>> * Basically fool-proof. Communicates simply what its function is (you
>> include this file once). Semantically it is "the right tool for the
>> job".
>> * No need for namespacing conventions for #include guards.
>> * No conflicts with reserved identifiers[5].
>> * No internal conflicts between include guards in Stout, Process
>> library, and Mesos (this is one reason we need the namespacing
>> conventions)
>> * Reduces preprocessor definition clutter (we should rely on #define
>> as little as humanly possible).
>> * Optimized to be easy to read and reason about.
>>
>> NEXT STEPS:
>> If we agree that this is the right thing to do, committers would ask
>> people to use `#pragma once` for new code when presented in code
>> reviews. For files that exist, I will take point on transitioning as
>> we complete the Windows integration work. I expect 

Re: Proposal: move towards #pragma and away from #include guards

[Alexander Rojas]

While I’m all in on the proposal, we did have this discussion almost a year ago 
[1] at the end I think, the decision was not to use them, though I don’t 
remember the exact reason. In any case, I vote +1 non-binding.

[1] 
http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E
 



> On 05 Nov 2015, at 06:36, Alex Clemmer  wrote:
> 
> Hey folks.
> 
> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> brought up the issue of moving away from #include guards and towards
> `#pragma once`.
> 
> As this has been brought up before, I will be brief: we think it's
> revisiting because the primary objection in previous threads appears
> to be that, though `#pragma once` is a cleaner solution to the
> multiple-include problem, it's not so much better that it's worth the
> code churn. However, the ongoing Windows integration work means we
> have to touch these files anyway, so if we agree this is cleaner and
> desirable, then this is an opportunity to obtain that additional code
> clarity, without the cost of the churn.
> 
> For the remainder of the email, I will summarize the history of our
> discussion of this issue, who will do the work, and what the next
> steps are.
> 
> PROPOSAL: We propose that all new code use `#pragma once` instead of
> #include guards; for existing files, we propose that you change
> #include guards when you touch them.
> 
> HISTORY: This has been discussed before, most recently a year ago on
> the mailing list[2]. There is a relevant JIRA[3] and discarded
> review[4] that changes style guide's recommendation on the matter.
> 
> SUMMARIZED OBJECTIONS:
> 1. The Google style guide explicitly forbids `#pragma once`.
> 2. This results in a lot of code churn, but is only marginally better.
> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> doesn't support it.
> 4. Popular projects like Chrome don't do `#pragma once` because of
> history clutter.
> 5. Intermediate state of inconsistency as we transition to `#pragma
> once` from #include guards.
> 
> OUR RESPONSE:
> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> points out in a previous thread that the Google style guide was
> canonized when `#pragma once` was Windows-only, and the guidance has
> not changed since because of the history churn problem. As noted
> above, we think the history churn problem is minimized by the fact
> that it can be wrapped up into the Windows integration work.
> 
> For objection (3), the consensus seems to be that the vast majority of
> compilers we care about (in particular, the ones supporting C++ 11) do
> support it.
> 
> For objection (5) we believe the inconsistent state is likely to not
> be long lived, as long as we commit to wrapping this work up into the
> Windows integration work.
> 
> SUMMARIZED ADVANTAGES:
> * Basically fool-proof. Communicates simply what its function is (you
> include this file once). Semantically it is "the right tool for the
> job".
> * No need for namespacing conventions for #include guards.
> * No conflicts with reserved identifiers[5].
> * No internal conflicts between include guards in Stout, Process
> library, and Mesos (this is one reason we need the namespacing
> conventions)
> * Reduces preprocessor definition clutter (we should rely on #define
> as little as humanly possible).
> * Optimized to be easy to read and reason about.
> 
> NEXT STEPS:
> If we agree that this is the right thing to do, committers would ask
> people to use `#pragma once` for new code when presented in code
> reviews. For files that exist, I will take point on transitioning as
> we complete the Windows integration work. I expect this work to
> completely land before the new year.
> 
> 
> Thanks,
> 
> 
> [1] https://reviews.apache.org/r/39803/
> [2] https://www.marc.info/?t=142540100400015=1=2
> [3] https://issues.apache.org/jira/browse/MESOS-2211
> [4] https://reviews.apache.org/r/30100/
> [5] 
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> 
> 
> -- 
> Alex
> 
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)

Re: Welcome Kapil as Mesos committer and PMC member!

[gilbert]

Congrats, Kapil!

Gilbert

> On Nov 5, 2015, at 2:02 AM, Till Toenshoff  wrote:
> 
> I'm happy to announce that Kapil Arya has been voted a Mesos committer and 
> PMC member!
> 
> Welcome Kapil, and thanks for all of your great contributions to the project 
> so far! 
> 
> Looking forward to lots more of your contributions!
> 
> Thanks
> Till

Re: Towards Mesos release 0.26.0

[Till Toenshoff]

As announced, we will be cutting the next release tomorrow, 6th of November. 

We currently have 130 blockers (as shown at 
https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12327111 
).

If you have any blocking issues assigned to yourself or if you are shepherding 
any of those, please make sure you update the target version unless you 
*really* want to block the 0.26 release. A quick fly-over seemed to suggest 
that only one of those actually should block 0.26; MESOS-2864 which will likely 
get solved today / tomorrow (thanks Vinod!).

Please answer this mail if you think your issues should be blocking the 
release, otherwise we will go ahead and move all those 129 issues to the next 
release.

Thanks for your help!
Till

> On Oct 19, 2015, at 3:44 PM, Bernd Mathiske  wrote:
> 
> Dear Mesos fans,
> 
> this is the tracking ticket for the upcoming next Mesos release.
> 
> https://issues.apache.org/jira/browse/MESOS-3758 
> 
> 
> Please read the ticket’s description for further instructions and tips on how 
> to get features and other improvements included.
> 
> The release managers will be Till and Bernd. If you have any questions, don’t 
> hesitate to post them here or contact us directly:
> 
> {till, bernd}mesosphere.io
> 
> We aim at making the first cut with a tag around November 6 and at finalizing 
> the release before November 17.
> 
> Best greetings,
> 
> Till and Bernd
> 

Re: Towards Mesos release 0.26.0

[Alex Clemmer]

Just for closure, it looks like a stunning 78% of these are due to me
(they are Windows integration-related). Since probably all of these
are not actually blocking 0.26, I will un/re-tag as appropriate today.

Also, I do apologize for making the issue graph a hockey stick.

On Thu, Nov 5, 2015 at 9:02 AM, Till Toenshoff  wrote:
> As announced, we will be cutting the next release tomorrow, 6th of November.
>
> We currently have 130 blockers (as shown at
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12327111).
>
> If you have any blocking issues assigned to yourself or if you are
> shepherding any of those, please make sure you update the target version
> unless you *really* want to block the 0.26 release. A quick fly-over seemed
> to suggest that only one of those actually should block 0.26; MESOS-2864
> which will likely get solved today / tomorrow (thanks Vinod!).
>
> Please answer this mail if you think your issues should be blocking the
> release, otherwise we will go ahead and move all those 129 issues to the
> next release.
>
> Thanks for your help!
> Till
>
> On Oct 19, 2015, at 3:44 PM, Bernd Mathiske  wrote:
>
> Dear Mesos fans,
>
> this is the tracking ticket for the upcoming next Mesos release.
>
> https://issues.apache.org/jira/browse/MESOS-3758
>
> Please read the ticket’s description for further instructions and tips on
> how to get features and other improvements included.
>
> The release managers will be Till and Bernd. If you have any questions,
> don’t hesitate to post them here or contact us directly:
>
> {till, bernd}mesosphere.io
>
> We aim at making the first cut with a tag around November 6 and at
> finalizing the release before November 17.
>
> Best greetings,
>
> Till and Bernd
>
>



-- 
Alex

Theory is the first term in the Taylor series of practice. -- Thomas M
Cover (1992)

Re: Proposal: move towards #pragma and away from #include guards

[Artem Harutyunyan]

Hi Alex,

While I agree with the idea in general, I strongly believe that we should
either leave it as it is or fix everything in one go (i.e. three
consecutive commits). Having both #include guards and #pragmas in the
codebase will be confusing and untidy. We have done code sweeps like this
in the past when we had to introduce changes to the style guide, so if
folks agree you just need to find a shepherd and do it :).

Cheers,
Artem.

On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer 
wrote:

> Hey folks.
>
> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> brought up the issue of moving away from #include guards and towards
> `#pragma once`.
>
> As this has been brought up before, I will be brief: we think it's
> revisiting because the primary objection in previous threads appears
> to be that, though `#pragma once` is a cleaner solution to the
> multiple-include problem, it's not so much better that it's worth the
> code churn. However, the ongoing Windows integration work means we
> have to touch these files anyway, so if we agree this is cleaner and
> desirable, then this is an opportunity to obtain that additional code
> clarity, without the cost of the churn.
>
> For the remainder of the email, I will summarize the history of our
> discussion of this issue, who will do the work, and what the next
> steps are.
>
> PROPOSAL: We propose that all new code use `#pragma once` instead of
> #include guards; for existing files, we propose that you change
> #include guards when you touch them.
>
> HISTORY: This has been discussed before, most recently a year ago on
> the mailing list[2]. There is a relevant JIRA[3] and discarded
> review[4] that changes style guide's recommendation on the matter.
>
> SUMMARIZED OBJECTIONS:
> 1. The Google style guide explicitly forbids `#pragma once`.
> 2. This results in a lot of code churn, but is only marginally better.
> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> doesn't support it.
> 4. Popular projects like Chrome don't do `#pragma once` because of
> history clutter.
> 5. Intermediate state of inconsistency as we transition to `#pragma
> once` from #include guards.
>
> OUR RESPONSE:
> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> points out in a previous thread that the Google style guide was
> canonized when `#pragma once` was Windows-only, and the guidance has
> not changed since because of the history churn problem. As noted
> above, we think the history churn problem is minimized by the fact
> that it can be wrapped up into the Windows integration work.
>
> For objection (3), the consensus seems to be that the vast majority of
> compilers we care about (in particular, the ones supporting C++ 11) do
> support it.
>
> For objection (5) we believe the inconsistent state is likely to not
> be long lived, as long as we commit to wrapping this work up into the
> Windows integration work.
>
> SUMMARIZED ADVANTAGES:
> * Basically fool-proof. Communicates simply what its function is (you
> include this file once). Semantically it is "the right tool for the
> job".
> * No need for namespacing conventions for #include guards.
> * No conflicts with reserved identifiers[5].
> * No internal conflicts between include guards in Stout, Process
> library, and Mesos (this is one reason we need the namespacing
> conventions)
> * Reduces preprocessor definition clutter (we should rely on #define
> as little as humanly possible).
> * Optimized to be easy to read and reason about.
>
> NEXT STEPS:
> If we agree that this is the right thing to do, committers would ask
> people to use `#pragma once` for new code when presented in code
> reviews. For files that exist, I will take point on transitioning as
> we complete the Windows integration work. I expect this work to
> completely land before the new year.
>
>
> Thanks,
>
>
> [1] https://reviews.apache.org/r/39803/
> [2] https://www.marc.info/?t=142540100400015=1=2
> [3] https://issues.apache.org/jira/browse/MESOS-2211
> [4] https://reviews.apache.org/r/30100/
> [5]
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
>
>
> --
> Alex
>
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)
>

Re: Proposal: move towards #pragma and away from #include guards

[Alexander Rojas]

my fault, I started reading at the office and when I came home I thought I had 
already read your whole email. Still, I have always been in favor or the 
`#pragma once` solution. So as I said:

+1 (non-binding).

> On 05 Nov 2015, at 18:21, Alex Clemmer  wrote:
> 
> Just because I apparently was not very clear: in the "history" and
> "summarized objections" sections of my original mail, I did attempt to
> capture all of the objections from this thread and previous
> discussions I found (and, just for the sake of thoroughness, I do
> actually explicitly cite this thread in the footnotes). If you don't
> want to dig through the thread yourself, I hope that this will give
> you a good approximation of what happened in that thread.
> 
> I see now that I did fail to mention that this thread ended in
> nonconsensus rather than an explicit decision against. Sorry about
> that. You can also see evidence that the decision was nonconsensus
> directly in the JIRA issues and the review I cite -- for example on
> JIRA, Alex R mentions removing the newbie tag from the issue because
> there is nonconsensus, and the review was discarded, with the cited
> reason being nonconsensus.
> 
> Hopefully this clarifies these issues.
> 
> On Thu, Nov 5, 2015 at 8:32 AM, Alexander Rojas  
> wrote:
>> While I’m all in on the proposal, we did have this discussion almost a year 
>> ago [1] at the end I think, the decision was not to use them, though I don’t 
>> remember the exact reason. In any case, I vote +1 non-binding.
>> 
>> [1] 
>> http://mail-archives.apache.org/mod_mbox/mesos-dev/201501.mbox/%3CCA+fJHLjzxPTk_Ry7-KSj1B-02Rp8Jt4ZUkkM2fH6uhbwR=i...@mail.gmail.com%3E
>>  
>> 
>> 
>> 
>>> On 05 Nov 2015, at 06:36, Alex Clemmer  wrote:
>>> 
>>> Hey folks.
>>> 
>>> In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
>>> brought up the issue of moving away from #include guards and towards
>>> `#pragma once`.
>>> 
>>> As this has been brought up before, I will be brief: we think it's
>>> revisiting because the primary objection in previous threads appears
>>> to be that, though `#pragma once` is a cleaner solution to the
>>> multiple-include problem, it's not so much better that it's worth the
>>> code churn. However, the ongoing Windows integration work means we
>>> have to touch these files anyway, so if we agree this is cleaner and
>>> desirable, then this is an opportunity to obtain that additional code
>>> clarity, without the cost of the churn.
>>> 
>>> For the remainder of the email, I will summarize the history of our
>>> discussion of this issue, who will do the work, and what the next
>>> steps are.
>>> 
>>> PROPOSAL: We propose that all new code use `#pragma once` instead of
>>> #include guards; for existing files, we propose that you change
>>> #include guards when you touch them.
>>> 
>>> HISTORY: This has been discussed before, most recently a year ago on
>>> the mailing list[2]. There is a relevant JIRA[3] and discarded
>>> review[4] that changes style guide's recommendation on the matter.
>>> 
>>> SUMMARIZED OBJECTIONS:
>>> 1. The Google style guide explicitly forbids `#pragma once`.
>>> 2. This results in a lot of code churn, but is only marginally better.
>>> 3. It's not C++ standardized/it's platform dependent/IBM's compiler
>>> doesn't support it.
>>> 4. Popular projects like Chrome don't do `#pragma once` because of
>>> history clutter.
>>> 5. Intermediate state of inconsistency as we transition to `#pragma
>>> once` from #include guards.
>>> 
>>> OUR RESPONSE:
>>> Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
>>> points out in a previous thread that the Google style guide was
>>> canonized when `#pragma once` was Windows-only, and the guidance has
>>> not changed since because of the history churn problem. As noted
>>> above, we think the history churn problem is minimized by the fact
>>> that it can be wrapped up into the Windows integration work.
>>> 
>>> For objection (3), the consensus seems to be that the vast majority of
>>> compilers we care about (in particular, the ones supporting C++ 11) do
>>> support it.
>>> 
>>> For objection (5) we believe the inconsistent state is likely to not
>>> be long lived, as long as we commit to wrapping this work up into the
>>> Windows integration work.
>>> 
>>> SUMMARIZED ADVANTAGES:
>>> * Basically fool-proof. Communicates simply what its function is (you
>>> include this file once). Semantically it is "the right tool for the
>>> job".
>>> * No need for namespacing conventions for #include guards.
>>> * No conflicts with reserved identifiers[5].
>>> * No internal conflicts between include guards in Stout, Process
>>> library, and Mesos (this is one reason we need the namespacing
>>> conventions)
>>> * Reduces 

Re: Proposal: move towards #pragma and away from #include guards

[Kapil Arya]

+1.

I think we should do it all at once as Artem mentioned. This doesn't really
affect the history (git-blame, etc.) because we are not touching code per
se.

On Thu, Nov 5, 2015 at 12:29 PM, Artem Harutyunyan 
wrote:

> Hi Alex,
>
> While I agree with the idea in general, I strongly believe that we should
> either leave it as it is or fix everything in one go (i.e. three
> consecutive commits). Having both #include guards and #pragmas in the
> codebase will be confusing and untidy. We have done code sweeps like this
> in the past when we had to introduce changes to the style guide, so if
> folks agree you just need to find a shepherd and do it :).
>
> Cheers,
> Artem.
>
> On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer 
> wrote:
>
> > Hey folks.
> >
> > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > brought up the issue of moving away from #include guards and towards
> > `#pragma once`.
> >
> > As this has been brought up before, I will be brief: we think it's
> > revisiting because the primary objection in previous threads appears
> > to be that, though `#pragma once` is a cleaner solution to the
> > multiple-include problem, it's not so much better that it's worth the
> > code churn. However, the ongoing Windows integration work means we
> > have to touch these files anyway, so if we agree this is cleaner and
> > desirable, then this is an opportunity to obtain that additional code
> > clarity, without the cost of the churn.
> >
> > For the remainder of the email, I will summarize the history of our
> > discussion of this issue, who will do the work, and what the next
> > steps are.
> >
> > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > #include guards; for existing files, we propose that you change
> > #include guards when you touch them.
> >
> > HISTORY: This has been discussed before, most recently a year ago on
> > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > review[4] that changes style guide's recommendation on the matter.
> >
> > SUMMARIZED OBJECTIONS:
> > 1. The Google style guide explicitly forbids `#pragma once`.
> > 2. This results in a lot of code churn, but is only marginally better.
> > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > doesn't support it.
> > 4. Popular projects like Chrome don't do `#pragma once` because of
> > history clutter.
> > 5. Intermediate state of inconsistency as we transition to `#pragma
> > once` from #include guards.
> >
> > OUR RESPONSE:
> > Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> > points out in a previous thread that the Google style guide was
> > canonized when `#pragma once` was Windows-only, and the guidance has
> > not changed since because of the history churn problem. As noted
> > above, we think the history churn problem is minimized by the fact
> > that it can be wrapped up into the Windows integration work.
> >
> > For objection (3), the consensus seems to be that the vast majority of
> > compilers we care about (in particular, the ones supporting C++ 11) do
> > support it.
> >
> > For objection (5) we believe the inconsistent state is likely to not
> > be long lived, as long as we commit to wrapping this work up into the
> > Windows integration work.
> >
> > SUMMARIZED ADVANTAGES:
> > * Basically fool-proof. Communicates simply what its function is (you
> > include this file once). Semantically it is "the right tool for the
> > job".
> > * No need for namespacing conventions for #include guards.
> > * No conflicts with reserved identifiers[5].
> > * No internal conflicts between include guards in Stout, Process
> > library, and Mesos (this is one reason we need the namespacing
> > conventions)
> > * Reduces preprocessor definition clutter (we should rely on #define
> > as little as humanly possible).
> > * Optimized to be easy to read and reason about.
> >
> > NEXT STEPS:
> > If we agree that this is the right thing to do, committers would ask
> > people to use `#pragma once` for new code when presented in code
> > reviews. For files that exist, I will take point on transitioning as
> > we complete the Windows integration work. I expect this work to
> > completely land before the new year.
> >
> >
> > Thanks,
> >
> >
> > [1] https://reviews.apache.org/r/39803/
> > [2] https://www.marc.info/?t=142540100400015=1=2
> > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > [4] https://reviews.apache.org/r/30100/
> > [5]
> >
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> >
> >
> > --
> > Alex
> >
> > Theory is the first term in the Taylor series of practice. -- Thomas M
> > Cover (1992)
> >
>

Fwd: [jira] [Created] (MESOS-2353) Improve performance of the master's state.json endpoint for large clusters.

[Benjamin Mahler]

The benchmark can be written independently and should exist before the fix
so we can measure the improvement. Vinod sounds like you might be
interested in writing one while waiting for michael?

-- Forwarded message --
From: *Vinod Kone (JIRA)* 
Date: Thursday, November 5, 2015
Subject: [jira] [Created] (MESOS-2353) Improve performance of the master's
state.json endpoint for large clusters.
To: benjamin.mah...@gmail.com



[
https://issues.apache.org/jira/browse/MESOS-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991934#comment-14991934
]

Vinod Kone commented on MESOS-2353:
---

Sure. If reviews and design doc are out by monday, that should be fine. Can
you ping me on IRC when you are online? Want to get a sense of what's
coming.

> Improve performance of the master's state.json endpoint for large
clusters.
>
---
>
> Key: MESOS-2353
> URL: https://issues.apache.org/jira/browse/MESOS-2353
> Project: Mesos
>  Issue Type: Improvement
>  Components: master
>Reporter: Benjamin Mahler
>  Labels: newbie, scalability, twitter
>
> The master's state.json endpoint consistently takes a long time to
compute the JSON result, for large clusters:
> {noformat}
> $ time curl -s -o /dev/null localhost:5050/master/state.json
> Mon Jan 26 22:38:50 UTC 2015
> real  0m13.174s
> user  0m0.003s
> sys   0m0.022s
> {noformat}
> This can cause the master to get backlogged if there are many state.json
requests in flight.
> Looking at {{perf}} data, it seems most of the time is spent doing memory
allocation / de-allocation. This ticket will try to capture any low hanging
fruit to speed this up. Possibly we can leverage moves if they are not
already being used by the compiler.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Created] (MESOS-2353) Improve performance of the master's state.json endpoint for large clusters.

[Vinod Kone]

Definitely! I wasn't sure if Michael already added a benchmark as part of
this reviews/prototyping.

On Thu, Nov 5, 2015 at 8:40 AM, Benjamin Mahler 
wrote:

> The benchmark can be written independently and should exist before the fix
> so we can measure the improvement. Vinod sounds like you might be
> interested in writing one while waiting for michael?
>
>
> -- Forwarded message --
> From: *Vinod Kone (JIRA)* 
> Date: Thursday, November 5, 2015
> Subject: [jira] [Created] (MESOS-2353) Improve performance of the master's
> state.json endpoint for large clusters.
> To: benjamin.mah...@gmail.com
>
>
>
> [
> https://issues.apache.org/jira/browse/MESOS-2353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991934#comment-14991934
> ]
>
> Vinod Kone commented on MESOS-2353:
> ---
>
> Sure. If reviews and design doc are out by monday, that should be fine.
> Can you ping me on IRC when you are online? Want to get a sense of what's
> coming.
>
> > Improve performance of the master's state.json endpoint for large
> clusters.
> >
> ---
> >
> > Key: MESOS-2353
> > URL: https://issues.apache.org/jira/browse/MESOS-2353
> > Project: Mesos
> >  Issue Type: Improvement
> >  Components: master
> >Reporter: Benjamin Mahler
> >  Labels: newbie, scalability, twitter
> >
> > The master's state.json endpoint consistently takes a long time to
> compute the JSON result, for large clusters:
> > {noformat}
> > $ time curl -s -o /dev/null localhost:5050/master/state.json
> > Mon Jan 26 22:38:50 UTC 2015
> > real  0m13.174s
> > user  0m0.003s
> > sys   0m0.022s
> > {noformat}
> > This can cause the master to get backlogged if there are many state.json
> requests in flight.
> > Looking at {{perf}} data, it seems most of the time is spent doing
> memory allocation / de-allocation. This ticket will try to capture any low
> hanging fruit to speed this up. Possibly we can leverage moves if they are
> not already being used by the compiler.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>
>

Finish Oversubscription before 0.26.0?

[Bernd Mathiske]

All who worked on MESOS-354,

What’s the status of the Oversubscription epic? Can we already call it a 
feature in 0.26? Shall we wait a few days to finish it? Will it slip into 0.27?

I see only 6 unresolved tickets and lots of resolved ones here:

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


(Could you please assign someone to this ticket as overall responsible epic 
master?)

Bernd



signature.asc
Description: Message signed with OpenPGP using GPGMail

New Cloud Foundry Framework - Mesos & CloudFoundry Integration

[Deepak Vij (A)]

Hi folks, I just joined the Apache Mesos mailing list. I wanted to reach out to 
the community regarding the new CloudFoundry/Mesos framework we have developed 
in our Santa Clara Lab. We would like to contribute this work to the Mesos open 
source community. I am pretty sure that this contribution would be quite 
valuable for the community. Please let me know the process for contributing our 
work to the community. Thanks.

Regards,
Deepak K. Vij
(Telecom Software Strategist, Huawei Software Lab, Santa Clara)

Re: Welcome Kapil as Mesos committer and PMC member!

[Jie Yu]

Congrats Kapil!

On Thu, Nov 5, 2015 at 2:02 AM, Till Toenshoff  wrote:

> I'm happy to announce that Kapil Arya has been voted a Mesos committer and
> PMC member!
>
> Welcome Kapil, and thanks for all of your great contributions to the
> project so far!
>
> Looking forward to lots more of your contributions!
>
> Thanks
> Till

Re: Finish Oversubscription before 0.26.0?

[Niklas Nielsen]

Nope - go ahead and close

On Thu, Nov 5, 2015 at 10:24 AM, Jie Yu  wrote:

> I would say the MVP is done. Of course, there'll be some followup
> improvement to the feature, and all the remaining issues are within that
> category. I am fine resolving this epic. Any one has any objection?
>
> - Jie
>
> On Thu, Nov 5, 2015 at 10:18 AM, Bernd Mathiske 
> wrote:
>
>> All who worked on MESOS-354,
>>
>> What’s the status of the Oversubscription epic? Can we already call it a
>> feature in 0.26? Shall we wait a few days to finish it? Will it slip into
>> 0.27?
>>
>> I see only 6 unresolved tickets and lots of resolved ones here:
>>
>> https://issues.apache.org/jira/browse/MESOS-354
>>
>> (Could you please assign someone to this ticket as overall responsible
>> epic master?)
>>
>> Bernd
>>
>>
>


-- 
Niklas

Re: New Cloud Foundry Framework - Mesos & CloudFoundry Integration

[Greg Mann]

I think that the Mesos org. on github (https://github.com/mesos) hosts
similar projects, so perhaps that would be a suitable location?

On Thu, Nov 5, 2015 at 2:09 PM, Marco Massenzio  wrote:

> Hey Deepak,
>
> that's really exciting, great stuff!
>
> As Alex correctly pointed out, though, if we understand this correctly,
> your work is around a Mesos Framework, is that right?
> (what does the framework does?)
>
> If that's the case, it would not be part of the Mesos codebase proper, but
> should instead be released independently (ideally, following the Apache 2
> license framework) - if that's the case, I'm definitely not an expert, but
> there are folks here that would be happy and fully capable to help!
>
> Thanks for doing the work and sharing it: that's awesome.
>
> --
> *Marco Massenzio*
> Distributed Systems Engineer
> http://codetrips.com
>
> On Thu, Nov 5, 2015 at 12:27 PM, Alex Clemmer  >
> wrote:
>
> > The contribution documentation for the Mesos codebase is here:
> > http://mesos.apache.org/documentation/latest/submitting-a-patch/
> > That said, it is not clear (to me at least) what you mean. It sounds like
> > you've written a framework. Is that right? If so, the it seems like it
> > might not fit in the scope of the core Mesos code base.
> >
> > Sent from Outlook
> >
> > _
> > From: Deepak Vij (A) 
> > Sent: Thursday, November 5, 2015 12:04
> > Subject: New Cloud Foundry Framework - Mesos & CloudFoundry Integration
> > To:  
> >
> >
> > Hi folks, I just joined the Apache Mesos mailing list. I wanted to reach
> > out to the community regarding the new CloudFoundry/Mesos framework we
> have
> > developed in our Santa Clara Lab. We would like to contribute this work
> to
> > the Mesos open source community. I am pretty sure that this contribution
> > would be quite valuable for the community. Please let me know the process
> > for contributing our work to the community. Thanks.
> >
> > Regards,
> > Deepak K. Vij
> > (Telecom Software Strategist, Huawei Software Lab, Santa Clara)
> >
>

Re: Apache Mesos Community Sync

[Adam Bordelon]

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 you/Twitter still planning to host the community sync
>>> tomorrow?
>>>
>>> On Wed, Oct 14, 2015 at 1:01 AM, Adam Bordelon 
>>> wrote:
>>>
 We'll have the next community sync this Thursday (Oct. 15th) from
 9-10am Pacific.

 Please add items to the agenda
 
 .


 We will use Hangouts on Air again. We will post the video stream link
 shortly before the meeting, and only active participants (especially people
 on the agenda) should join the actual hangout. Others can watch the video
 stream and ask brief questions on #mesos on IRC. If you have something
 lengthier to discuss, put it on the agenda and ping us on email/IRC to get
 into the hangout.

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


 On Thu, Oct 1, 2015 at 9:30 AM, haosdent  wrote:

> Got it. Thank you.
>
> On Fri, Oct 2, 2015 at 12:27 AM, Gilbert Song 
> wrote:
>
> > Yes, community sync is at 3 pm PST today afternoon. Video Link is
> still not
> > available. And here is the link for meeting agenda/notes:
> >
> >
> >
> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
> >
> > On Thu, Oct 1, 2015 at 9:19 AM, haosdent  wrote:
> >
> > > Do today have community sync?
> > >
> > > On Fri, Sep 18, 2015 at 12:59 AM, Adam Bordelon <
> a...@mesosphere.io>
> > > wrote:
> > >
> > > > Today's community sync video/audio is archived at:
> > > > http://youtu.be/ZQT6-fw8Ito
> > > > The meeting agenda/notes are available at:
> > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/153CUCj5LOJCFAVpdDZC7COJDwKh9RDjxaTA0S7lzwDA/edit?usp=sharing
> > > >
> > > > For convenience, today's notes are reproduced below:
> > > >
> > > >-
> > > >
> > > >0.21.2-0.24.1 Patch Releases [Adam]
> > > >-
> > > >
> > > >   What’s the plan for how many releases we want to support?
> BenH:
> > > >   Support at least 3 versions (e.g. 0.22.x, 0.23.x, 0.24.x)
> for
> > > > which we will
> > > >   do patch fixes
> > > >   Neil: Or support an LTS version + recent releases
> > > >   -
> > > >
> > > >   Separate Release Manager for backports? Joris and MPark
> will RM
> > for
> > > >   these patch releases, with Adam shepherding. In general,
> > > patch/point
> > > >   releases don’t need to be managed by the same person who
> did the
> > > > original
> > > >   release.
> > > >   -
> > > >
> > > >   Need some guidelines (on the website) for what is a
> > > >   backport-able/critical patch.
> > > >   -
> > > >
> > > >   AI[Adam+0.25RMs]: Expand Release Guide with # supported
> releases,
> > > >   guidelines for critical patches, RM roles/responsibilities
> > > >   -
> > > >
> > > >0.25.0 Release Planning[Joris]: Dashboard
> > > ><
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12326859
> > > > >
> > > >-
> > > >
> > > >   Planning a triage meeting for Friday, hope to 

Re: Welcome Kapil as Mesos committer and PMC member!

[Kapil Arya]

Thanks everyone! :-).



On Thu, Nov 5, 2015 at 3:50 PM, Elizabeth Lingg 
wrote:

> Congrats Professor! You definitely deserve it.
>
> -Elizabeth
>
> On Thu, Nov 5, 2015 at 10:53 AM, Jie Yu  wrote:
>
> > Congrats Kapil!
> >
> > On Thu, Nov 5, 2015 at 2:02 AM, Till Toenshoff  wrote:
> >
> > > I'm happy to announce that Kapil Arya has been voted a Mesos committer
> > and
> > > PMC member!
> > >
> > > Welcome Kapil, and thanks for all of your great contributions to the
> > > project so far!
> > >
> > > Looking forward to lots more of your contributions!
> > >
> > > Thanks
> > > Till
> >
>

Re: Welcome Kapil as Mesos committer and PMC member!

[Elizabeth Lingg]

Congrats Professor! You definitely deserve it.

-Elizabeth

On Thu, Nov 5, 2015 at 10:53 AM, Jie Yu  wrote:

> Congrats Kapil!
>
> On Thu, Nov 5, 2015 at 2:02 AM, Till Toenshoff  wrote:
>
> > I'm happy to announce that Kapil Arya has been voted a Mesos committer
> and
> > PMC member!
> >
> > Welcome Kapil, and thanks for all of your great contributions to the
> > project so far!
> >
> > Looking forward to lots more of your contributions!
> >
> > Thanks
> > Till
>

Re: Mesos Style Guideline Adjustments

[Benjamin Mahler]

This has come up in a couple of reviews, seems like we should add some soft
guidelines around how to format comments for readability.

In particular, the reason that we wrapped at 70 in the past was for
readability, so it would be great to continue doing so as a soft stylistic
rule. The other thing we've been doing for readability is reducing
"jaggedness" (variability in line lengths).

It would be great to establish these as soft rules and encourage new
contributors / committers to follow them. Compare these two comments in
Master::updateTask. The first one wraps at 70 and reduces jagedness, the
second wraps at 80 and is more jagged:

https://github.com/apache/mesos/blob/0.25.0/src/master/master.cpp#L6057
https://github.com/apache/mesos/blob/0.25.0/src/master/master.cpp#L6072

I can provide more examples to help clarify. If no one objects, I'll follow
up with an update to the style guide. Thoughts appreciated!

On Thu, Sep 10, 2015 at 8:59 AM, Bernd Mathiske  wrote:

> +1
> > On Sep 10, 2015, at 4:21 PM, tommy xiao  wrote:
> >
> > +1
> >
> > 2015-09-10 9:44 GMT+08:00 Marco Massenzio :
> >
> >> +1
> >>
> >>
> >>
> >>
> >> Thanks, Michael!
> >>
> >>
> >>
> >> —
> >> Sent from my iPhone, which is not as good as you'd hope to fix trypos n
> >> abbrvtn.
> >>
> >> On Wed, Sep 9, 2015 at 6:23 PM, Michael Park  wrote:
> >>
> >>> I've removed the 70 column restriction on comments from the style
> guide:
> >>>
> >>
> https://github.com/apache/mesos/commit/f9c2604ea97b91f8a9ec3b2863317761679b1c86
> >>> Also, based on the comments, it seems like we should allow 80 column
> >>> comments but omit the sweeping change.
> >>> Thanks,
> >>> MPark.
> >>> On Wed, Aug 12, 2015 at 6:13 PM Marco Massenzio 
> >> wrote:
>  On Wed, Aug 12, 2015 at 4:09 AM, Bernd Mathiske 
>  wrote:
> 
> > Like BenM,
> >
> > +1 on allowing 80 column comments
> >
>  +1
>  (it really IS annoying having to keep an eye on the bottom column
> >> counter
>  when typing comments :)
> 
> 
> > -1 on sweeping changes; incremental changes when touching old
> comments
> > will do IMHO
> >
> > +1 on the -1? :)
>  Incremental changes are good and I doubt anyone will be "confused" by
> >> them.
> 
> 
> > Bernd
> >
> >> On Aug 12, 2015, at 12:51 AM, Michael Park 
> >> wrote:
> >>
> >> Ben, thanks for your input!
> >>
> >> Another update on this topic: the patches around break before braces
>  for
> >> *enum* style and overloaded operators have been committed.
> >>
> >> On Tue, Aug 11, 2015 at 6:23 PM Benjamin Mahler <
> > benjamin.mah...@gmail.com>
> >> wrote:
> >>
> >>> We already don't necessarily wrap at 70 characters (often we wrap
> > before 70
> >>> to reduce "jaggedness" or to make it look cleaner).
> >>>
> >>> So with the change to 80, this still makes all existing comments
>  valid.
> > We
> >>> can still encourage folks to write paragraphs in a way that is
> >> easy to
> >>> digest for the reader. That is, I think we should still be trying
> >> not
>  to
> >>> write jagged paragraphs of comments, it's just not a hard stylistic
> >>> violation given we don't have an algorithm for this.
> >>>
> >>> So +1 to relaxing the hard 70 character rule, but -1 to sweeping
>  across
> > all
> >>> the comments or doing wrapping based only on line length rather
> >> than
> >>> jaggedness going forward.
> >>>
> >>> On Sat, Aug 8, 2015 at 3:25 PM, Joris Van Remoortere <
> > jo...@mesosphere.io>
> >>> wrote:
> >>>
>  I will volunteer to update all the comments to wrap at 80 if we
> >> agree
> > to
>  keep the code base consistent.
>  Naturally that is also my vote ;-)
>  Joris
> 
> > On Aug 8, 2015, at 1:40 PM, Michael Park 
> >> wrote:
> >
> > An update on this topic since we covered it at the community
>  developer
>  sync.
> >
> > 1. We will adopt *Mozilla*'s *BreakBeforeBraces* style as their
>  style
>  is
> > equivalent to ours. The only change this entails for our
> >> codebase
>  is
> >>> to
> > consistently wrap the braces for *enum* definitions, as we're
> >>> currently
> > inconsistent. I've taken on the work involved in this change:
> >- stout: https://reviews.apache.org/r/37258
> >- libprocess: https://reviews.apache.org/r/37259
> >- mesos: https://reviews.apache.org/r/37260
> >2. We will drop the rule for adding spaces around overloaded
> > operators. We'll simply do a sweep of the codebase to update
> >> all of
>  them
> > consistently. Artem has kindly taken action on 

Re: New Cloud Foundry Framework - Mesos & CloudFoundry Integration

[Marco Massenzio]

Hey Deepak,

that's really exciting, great stuff!

As Alex correctly pointed out, though, if we understand this correctly,
your work is around a Mesos Framework, is that right?
(what does the framework does?)

If that's the case, it would not be part of the Mesos codebase proper, but
should instead be released independently (ideally, following the Apache 2
license framework) - if that's the case, I'm definitely not an expert, but
there are folks here that would be happy and fully capable to help!

Thanks for doing the work and sharing it: that's awesome.

--
*Marco Massenzio*
Distributed Systems Engineer
http://codetrips.com

On Thu, Nov 5, 2015 at 12:27 PM, Alex Clemmer 
wrote:

> The contribution documentation for the Mesos codebase is here:
> http://mesos.apache.org/documentation/latest/submitting-a-patch/
> That said, it is not clear (to me at least) what you mean. It sounds like
> you've written a framework. Is that right? If so, the it seems like it
> might not fit in the scope of the core Mesos code base.
>
> Sent from Outlook
>
> _
> From: Deepak Vij (A) 
> Sent: Thursday, November 5, 2015 12:04
> Subject: New Cloud Foundry Framework - Mesos & CloudFoundry Integration
> To:  
>
>
> Hi folks, I just joined the Apache Mesos mailing list. I wanted to reach
> out to the community regarding the new CloudFoundry/Mesos framework we have
> developed in our Santa Clara Lab. We would like to contribute this work to
> the Mesos open source community. I am pretty sure that this contribution
> would be quite valuable for the community. Please let me know the process
> for contributing our work to the community. Thanks.
>
> Regards,
> Deepak K. Vij
> (Telecom Software Strategist, Huawei Software Lab, Santa Clara)
>

Re: New Cloud Foundry Framework - Mesos & CloudFoundry Integration

[Alex Clemmer]

The contribution documentation for the Mesos codebase is here: 
http://mesos.apache.org/documentation/latest/submitting-a-patch/
That said, it is not clear (to me at least) what you mean. It sounds like 
you've written a framework. Is that right? If so, the it seems like it might 
not fit in the scope of the core Mesos code base.

Sent from Outlook

_
From: Deepak Vij (A) 
Sent: Thursday, November 5, 2015 12:04
Subject: New Cloud Foundry Framework - Mesos & CloudFoundry Integration
To:  


Hi folks, I just joined the Apache Mesos mailing list. I wanted to reach out to 
the community regarding the new CloudFoundry/Mesos framework we have developed 
in our Santa Clara Lab. We would like to contribute this work to the Mesos open 
source community. I am pretty sure that this contribution would be quite 
valuable for the community. Please let me know the process for contributing our 
work to the community. Thanks.

Regards,
Deepak K. Vij
(Telecom Software Strategist, Huawei Software Lab, Santa Clara)

Re: Welcome Kapil as Mesos committer and PMC member!

[Brenden Matthews]

Awesome! Welcome Kapil!

On Thu, Nov 5, 2015 at 5:20 PM, Benjamin Mahler 
wrote:

> Congrats and welcome!
>
> On Thu, Nov 5, 2015 at 4:04 PM, Kapil Arya  wrote:
>
>> Thanks everyone! :-).
>>
>>
>>
>> On Thu, Nov 5, 2015 at 3:50 PM, Elizabeth Lingg 
>> wrote:
>>
>>> Congrats Professor! You definitely deserve it.
>>>
>>> -Elizabeth
>>>
>>> On Thu, Nov 5, 2015 at 10:53 AM, Jie Yu  wrote:
>>>
>>> > Congrats Kapil!
>>> >
>>> > On Thu, Nov 5, 2015 at 2:02 AM, Till Toenshoff 
>>> wrote:
>>> >
>>> > > I'm happy to announce that Kapil Arya has been voted a Mesos
>>> committer
>>> > and
>>> > > PMC member!
>>> > >
>>> > > Welcome Kapil, and thanks for all of your great contributions to the
>>> > > project so far!
>>> > >
>>> > > Looking forward to lots more of your contributions!
>>> > >
>>> > > Thanks
>>> > > Till
>>> >
>>>
>>
>>
>

Re: Welcome Kapil as Mesos committer and PMC member!

[Benjamin Mahler]

Congrats and welcome!

On Thu, Nov 5, 2015 at 4:04 PM, Kapil Arya  wrote:

> Thanks everyone! :-).
>
>
>
> On Thu, Nov 5, 2015 at 3:50 PM, Elizabeth Lingg 
> wrote:
>
>> Congrats Professor! You definitely deserve it.
>>
>> -Elizabeth
>>
>> On Thu, Nov 5, 2015 at 10:53 AM, Jie Yu  wrote:
>>
>> > Congrats Kapil!
>> >
>> > On Thu, Nov 5, 2015 at 2:02 AM, Till Toenshoff 
>> wrote:
>> >
>> > > I'm happy to announce that Kapil Arya has been voted a Mesos committer
>> > and
>> > > PMC member!
>> > >
>> > > Welcome Kapil, and thanks for all of your great contributions to the
>> > > project so far!
>> > >
>> > > Looking forward to lots more of your contributions!
>> > >
>> > > Thanks
>> > > Till
>> >
>>
>
>

Re: Proposal: move towards #pragma and away from #include guards

[Joris Van Remoortere]

+1 with all-at-once

—
*Joris Van Remoortere*
Mesosphere

On Thu, Nov 5, 2015 at 9:37 AM, Kapil Arya  wrote:

> +1.
>
> I think we should do it all at once as Artem mentioned. This doesn't really
> affect the history (git-blame, etc.) because we are not touching code per
> se.
>
> On Thu, Nov 5, 2015 at 12:29 PM, Artem Harutyunyan 
> wrote:
>
> > Hi Alex,
> >
> > While I agree with the idea in general, I strongly believe that we should
> > either leave it as it is or fix everything in one go (i.e. three
> > consecutive commits). Having both #include guards and #pragmas in the
> > codebase will be confusing and untidy. We have done code sweeps like this
> > in the past when we had to introduce changes to the style guide, so if
> > folks agree you just need to find a shepherd and do it :).
> >
> > Cheers,
> > Artem.
> >
> > On Wed, Nov 4, 2015 at 9:36 PM, Alex Clemmer <
> clemmer.alexan...@gmail.com>
> > wrote:
> >
> > > Hey folks.
> > >
> > > In r/39803[1], Mike Hopcroft (in quintessential MSFT style, heh)
> > > brought up the issue of moving away from #include guards and towards
> > > `#pragma once`.
> > >
> > > As this has been brought up before, I will be brief: we think it's
> > > revisiting because the primary objection in previous threads appears
> > > to be that, though `#pragma once` is a cleaner solution to the
> > > multiple-include problem, it's not so much better that it's worth the
> > > code churn. However, the ongoing Windows integration work means we
> > > have to touch these files anyway, so if we agree this is cleaner and
> > > desirable, then this is an opportunity to obtain that additional code
> > > clarity, without the cost of the churn.
> > >
> > > For the remainder of the email, I will summarize the history of our
> > > discussion of this issue, who will do the work, and what the next
> > > steps are.
> > >
> > > PROPOSAL: We propose that all new code use `#pragma once` instead of
> > > #include guards; for existing files, we propose that you change
> > > #include guards when you touch them.
> > >
> > > HISTORY: This has been discussed before, most recently a year ago on
> > > the mailing list[2]. There is a relevant JIRA[3] and discarded
> > > review[4] that changes style guide's recommendation on the matter.
> > >
> > > SUMMARIZED OBJECTIONS:
> > > 1. The Google style guide explicitly forbids `#pragma once`.
> > > 2. This results in a lot of code churn, but is only marginally better.
> > > 3. It's not C++ standardized/it's platform dependent/IBM's compiler
> > > doesn't support it.
> > > 4. Popular projects like Chrome don't do `#pragma once` because of
> > > history clutter.
> > > 5. Intermediate state of inconsistency as we transition to `#pragma
> > > once` from #include guards.
> > >
> > > OUR RESPONSE:
> > > Objections (1), (2), and (4) are essentially the same -- Dominic Hamon
> > > points out in a previous thread that the Google style guide was
> > > canonized when `#pragma once` was Windows-only, and the guidance has
> > > not changed since because of the history churn problem. As noted
> > > above, we think the history churn problem is minimized by the fact
> > > that it can be wrapped up into the Windows integration work.
> > >
> > > For objection (3), the consensus seems to be that the vast majority of
> > > compilers we care about (in particular, the ones supporting C++ 11) do
> > > support it.
> > >
> > > For objection (5) we believe the inconsistent state is likely to not
> > > be long lived, as long as we commit to wrapping this work up into the
> > > Windows integration work.
> > >
> > > SUMMARIZED ADVANTAGES:
> > > * Basically fool-proof. Communicates simply what its function is (you
> > > include this file once). Semantically it is "the right tool for the
> > > job".
> > > * No need for namespacing conventions for #include guards.
> > > * No conflicts with reserved identifiers[5].
> > > * No internal conflicts between include guards in Stout, Process
> > > library, and Mesos (this is one reason we need the namespacing
> > > conventions)
> > > * Reduces preprocessor definition clutter (we should rely on #define
> > > as little as humanly possible).
> > > * Optimized to be easy to read and reason about.
> > >
> > > NEXT STEPS:
> > > If we agree that this is the right thing to do, committers would ask
> > > people to use `#pragma once` for new code when presented in code
> > > reviews. For files that exist, I will take point on transitioning as
> > > we complete the Windows integration work. I expect this work to
> > > completely land before the new year.
> > >
> > >
> > > Thanks,
> > >
> > >
> > > [1] https://reviews.apache.org/r/39803/
> > > [2] https://www.marc.info/?t=142540100400015=1=2
> > > [3] https://issues.apache.org/jira/browse/MESOS-2211
> > > [4] https://reviews.apache.org/r/30100/
> > > [5]
> > >
> >
> http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier
> > >

Re: [jira] [Comment Edited] (MESOS-2079) IO.Write test is flaky on OS X 10.10.

[Benjamin Mahler]

Just want to surface this up to the dev@ thread to raise some awareness.
Recently with the SIGPIPE bug from libev [1], we've revisited whether it
makes sense to continue down the path of leaving SIGPIPE unblocked and
trying to handle it case by case.

We originally wanted users of libprocess to decide on their own whether
they want to ignore SIGPIPE. However, we'd like to reconsider:

(a) The amount of code that is needed to work around SIGPIPE is
substantial, especially because on OS X SIGPIPE appears to not be delivered
synchronously [2]. Also, it is not possible to create pipes that don't
surface SIGPIPE (unlike sockets), so in order to safely write to a pipe we
need to wrap write() calls with signal suppression blocks (which we don't
do in general!). You can get a sense of the code from [3] and [4].

(b) SIGPIPE seems to be more of a legacy mechanism to shut down a set of
piped programs and the general recommendation seems to be to not bother
with it and ignore it. Programs can handle EPIPE as they would with other
signals.

Would love to hear if there are any concerns. I will be glad to shepherd
James' changes here.

[1] https://issues.apache.org/jira/browse/MESOS-2768
[2] https://issues.apache.org/jira/browse/MESOS-2079
[3] https://reviews.apache.org/r/39940/diff/1#index_header
[4]
https://github.com/apache/mesos/blob/0.25.0/3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/signals.hpp#L101

On Wed, Nov 4, 2015 at 9:20 AM, James Peach (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/MESOS-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14989947#comment-14989947
> ]
>
> James Peach edited comment on MESOS-2079 at 11/4/15 5:19 PM:
> -
>
> These patches global ignore {{SIGPIPE}} during libprocess initialization,
> document {{SIGPIPE}} behavior a bit more, and remove various signal
> manipulations that were formerly necessary for disabling {{SIGPIPE}}
> delivery.
>
> https://reviews.apache.org/r/39938/
> https://reviews.apache.org/r/39940/
> https://reviews.apache.org/r/39941/
>
>
>
> was (Author: jamespeach):
> https://reviews.apache.org/r/39938/
> https://reviews.apache.org/r/39940/
> https://reviews.apache.org/r/39941/
>
>
> > IO.Write test is flaky on OS X 10.10.
> > -
> >
> > Key: MESOS-2079
> > URL: https://issues.apache.org/jira/browse/MESOS-2079
> > Project: Mesos
> >  Issue Type: Task
> >  Components: libprocess, technical debt, test
> > Environment: OS X 10.10
> > {noformat}
> > $ clang++ --version
> > Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
> > Target: x86_64-apple-darwin14.0.0
> > Thread model: posix
> > {noformat}
> >Reporter: Benjamin Mahler
> >Assignee: James Peach
> >  Labels: flaky
> >
> > [~benjaminhindman]: If I recall correctly, this is related to
> MESOS-1658. Unfortunately, we don't have a stacktrace for SIGPIPE currently:
> > {noformat}
> > [ RUN  ] IO.Write
> > make[5]: *** [check-local] Broken pipe: 13
> > {noformat}
> > Running in gdb, seems to always occur here:
> > {code}
> > Program received signal SIGPIPE, Broken pipe.
> > [Switching to process 56827 thread 0x60b]
> > 0x7fff9a011132 in __psynch_cvwait ()
> > (gdb) where
> > #0  0x7fff9a011132 in __psynch_cvwait ()
> > #1  0x7fff903e7ea0 in _pthread_cond_wait ()
> > #2  0x00010062f27c in Gate::arrive (this=0x101908a10, old=14780) at
> gate.hpp:82
> > #3  0x000100600888 in process::schedule (arg=0x0) at
> src/process.cpp:1373
> > #4  0x7fff903e72fc in _pthread_body ()
> > #5  0x7fff903e7279 in _pthread_start ()
> > #6  0x7fff903e54b1 in thread_start ()
> > {code}
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Re: Welcome Kapil as Mesos committer and PMC member!

[Alexander Rojas]

Congrats Kapil. This is really worth to be celebrated.

> On 05 Nov 2015, at 11:02, Till Toenshoff  wrote:
> 
> I'm happy to announce that Kapil Arya has been voted a Mesos committer and 
> PMC member!
> 
> Welcome Kapil, and thanks for all of your great contributions to the project 
> so far! 
> 
> Looking forward to lots more of your contributions!
> 
> Thanks
> Till