You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Cong Wang <cw...@twopensource.com> on 2016/03/15 19:45:01 UTC

Backport r/44230 to 0.27 branch

Hi, all

I don't know what is the process to request for a backport for Mesos
stable releases and how Mesos community cares about stable releases.
But... please consider to backport the following patch to at least
0.27 branch:

https://reviews.apache.org/r/44230/

It fixes a bug in our production which causes GC failed to prune a directory.

The backport should be very straightforward. Please let me know if I
can help anything.

BTW, for Linux kernel we evaluate every bug fix to make sure it is
backported to the right stable releases.

Thanks.

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Tue, Mar 15, 2016 at 5:17 PM, Jie Yu <yu...@gmail.com> wrote:
> commit 5278e5cc50544ed7af28b15a1acd2b2e96a15a47
> Author: Jojy Varghese <jo...@mesosphere.io>
> Date:   Tue Mar 15 17:12:01 2016 -0700
>
>     Added support for FTS_SLNONE in rmdir.
>
>     Review: https://reviews.apache.org/r/44874/
>
> commit 5c4b348c8090ce61804b7701e3b0705ced975a7e
> Author: Jojy Varghese <jo...@mesosphere.io>
> Date:   Tue Mar 15 17:11:54 2016 -0700
>
>     Added test for rmdir with device file.
>
>     Existing tests did not cover the case of removing directories with
>     special files like device files.
>
>     Review: https://reviews.apache.org/r/44873/
>

Will they be backported as well?

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
commit 5278e5cc50544ed7af28b15a1acd2b2e96a15a47
Author: Jojy Varghese <jo...@mesosphere.io>
Date:   Tue Mar 15 17:12:01 2016 -0700

    Added support for FTS_SLNONE in rmdir.

    Review: https://reviews.apache.org/r/44874/

commit 5c4b348c8090ce61804b7701e3b0705ced975a7e
Author: Jojy Varghese <jo...@mesosphere.io>
Date:   Tue Mar 15 17:11:54 2016 -0700

    Added test for rmdir with device file.

    Existing tests did not cover the case of removing directories with
    special files like device files.

    Review: https://reviews.apache.org/r/44873/

- Jie

On Tue, Mar 15, 2016 at 2:46 PM, Jie Yu <yu...@gmail.com> wrote:
> Also, I think we should fix the TODO in rmdir as well (i.e., handle
> FTS_SLNONE as well as Neil suggested).
>
> - Jie
>
> On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Mesos currently has no notion of long term stable releases (i.e., LTS). I
>> think the consensus in the last community sync was to introduce LTS after
>> 1.0.
>>
>> 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
>> backport it.
>>
>> I am OK with back porting it. Then the question is that whether we want to
>> backport it to other releases as well.
>>
>> - Jie
>>
>> On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang <cw...@twopensource.com>
>> wrote:
>>>
>>> Hi, all
>>>
>>> I don't know what is the process to request for a backport for Mesos
>>> stable releases and how Mesos community cares about stable releases.
>>> But... please consider to backport the following patch to at least
>>> 0.27 branch:
>>>
>>> https://reviews.apache.org/r/44230/
>>>
>>> It fixes a bug in our production which causes GC failed to prune a
>>> directory.
>>>
>>> The backport should be very straightforward. Please let me know if I
>>> can help anything.
>>>
>>> BTW, for Linux kernel we evaluate every bug fix to make sure it is
>>> backported to the right stable releases.
>>>
>>> Thanks.
>>
>>
>

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
Also, I think we should fix the TODO in rmdir as well (i.e.,
handle FTS_SLNONE as well as Neil suggested).

- Jie

On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yu...@gmail.com> wrote:

> Mesos currently has no notion of long term stable releases (i.e., LTS). I
> think the consensus in the last community sync was to introduce LTS after
> 1.0.
>
> 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
> backport it.
>
> I am OK with back porting it. Then the question is that whether we want to
> backport it to other releases as well.
>
> - Jie
>
> On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang <cw...@twopensource.com>
> wrote:
>
>> Hi, all
>>
>> I don't know what is the process to request for a backport for Mesos
>> stable releases and how Mesos community cares about stable releases.
>> But... please consider to backport the following patch to at least
>> 0.27 branch:
>>
>> https://reviews.apache.org/r/44230/
>>
>> It fixes a bug in our production which causes GC failed to prune a
>> directory.
>>
>> The backport should be very straightforward. Please let me know if I
>> can help anything.
>>
>> BTW, for Linux kernel we evaluate every bug fix to make sure it is
>> backported to the right stable releases.
>>
>> Thanks.
>>
>
>

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 11:57 AM, Zameer Manji <zm...@apache.org> wrote:
> Cong brings up a good point here. Currently Mesos has a very aggressive
> release cadence. This results in several questions as a cluster operator
> and framework author.
>
>    - What is the support from the community/committers for each release?
>    - Do cluster operators and framework authors need to move at the same
>    space at the community?
>    - Will bugfixes be automatically backported?
>
> The lack of clarity here can result in several issues because it is easy
> for the Mesos PMC to cut releases quickly, but it isn't easy for people
> with existing clusters to upgrade at that pace. An aggressive release
> policy without clear support for older releases can leave several users in
> a bad position where they might need to upgrade Mesos through one (or
> more!) releases just to get a critical bugfix.
>

I think the core reason why Mesos community lacks this is there is not
a central maintainer who only/mostly handles maintenance stuffs,
is responsible for the quality of the whole project, and monitors each
release cycle.

Like Linux kernel, Linus is obviously the one who cuts the base releases
and monitors the overall project, he only takes pull requests from each
subsystem maintainers. Each subsystem maintainer needs to decide
what to send to Linus during this cycle.

Mesos has 20+ committers, all of them commit to the master branch,
which makes things worse without a central maintainer. Mesos release
managers are volunteers (from my observation) from the community
rather than a dedicated one, this makes it hard to find one responsible
for a specific release.

Just my 2 cents.

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
Zemeer, thanks for the input. I think we should discuss that in the next
community sync (can you join?). Vinod did some analysis on how people feel
about the release cadence, but I don't see that results being published.
Should we discuss that again and come up with some concrete action items?

- Jie

On Wed, Mar 16, 2016 at 11:57 AM, Zameer Manji <zm...@apache.org> wrote:

> Cong brings up a good point here. Currently Mesos has a very aggressive
> release cadence. This results in several questions as a cluster operator
> and framework author.
>
>    - What is the support from the community/committers for each release?
>    - Do cluster operators and framework authors need to move at the same
>    space at the community?
>    - Will bugfixes be automatically backported?
>
> The lack of clarity here can result in several issues because it is easy
> for the Mesos PMC to cut releases quickly, but it isn't easy for people
> with existing clusters to upgrade at that pace. An aggressive release
> policy without clear support for older releases can leave several users in
> a bad position where they might need to upgrade Mesos through one (or
> more!) releases just to get a critical bugfix.
>
>
>
> On Wed, Mar 16, 2016 at 11:44 AM, Cong Wang <cw...@twopensource.com>
> wrote:
>
> > On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yu...@gmail.com> wrote:
> > > Mesos currently has no notion of long term stable releases (i.e.,
> LTS). I
> > > think the consensus in the last community sync was to introduce LTS
> after
> > > 1.0.
> >
> >
> > You don't need LTS as kernel, even talking about short term stable
> releases
> > like 0.27.2 (?), they look horrible too, I don't see any git tags or
> > branches for
> > these releases, just a tar ball?! Huh...
> >
> >
> > >
> > > 0.27.2 has already been released. Looks like we need 0.27.3 if we want
> to
> > > backport it.
> >
> >
> > What determines which patches need to backport for Mesos community?
> > It doesn't look like every bug fix is evaluated and considered after they
> > are merged into master branch.
> >
> > >
> > > I am OK with back porting it. Then the question is that whether we want
> > to
> > > backport it to other releases as well.
> > >
> >
> > It should be backported to whichever releases it applies to and you
> > support,
> > I don't see Mesos community has such a procedure.
> >
> > --
> > Zameer Manji
> >
> >
>

Re: Backport r/44230 to 0.27 branch

Posted by Zameer Manji <zm...@apache.org>.
Cong brings up a good point here. Currently Mesos has a very aggressive
release cadence. This results in several questions as a cluster operator
and framework author.

   - What is the support from the community/committers for each release?
   - Do cluster operators and framework authors need to move at the same
   space at the community?
   - Will bugfixes be automatically backported?

The lack of clarity here can result in several issues because it is easy
for the Mesos PMC to cut releases quickly, but it isn't easy for people
with existing clusters to upgrade at that pace. An aggressive release
policy without clear support for older releases can leave several users in
a bad position where they might need to upgrade Mesos through one (or
more!) releases just to get a critical bugfix.



On Wed, Mar 16, 2016 at 11:44 AM, Cong Wang <cw...@twopensource.com> wrote:

> On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yu...@gmail.com> wrote:
> > Mesos currently has no notion of long term stable releases (i.e., LTS). I
> > think the consensus in the last community sync was to introduce LTS after
> > 1.0.
>
>
> You don't need LTS as kernel, even talking about short term stable releases
> like 0.27.2 (?), they look horrible too, I don't see any git tags or
> branches for
> these releases, just a tar ball?! Huh...
>
>
> >
> > 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
> > backport it.
>
>
> What determines which patches need to backport for Mesos community?
> It doesn't look like every bug fix is evaluated and considered after they
> are merged into master branch.
>
> >
> > I am OK with back porting it. Then the question is that whether we want
> to
> > backport it to other releases as well.
> >
>
> It should be backported to whichever releases it applies to and you
> support,
> I don't see Mesos community has such a procedure.
>
> --
> Zameer Manji
>
>

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 5:19 PM, Vinod Kone <vi...@apache.org> wrote:
> Cong, I understand your frustration with the review process and backports.
> I've already created a ticket to track the latter. Would love your
> input/feedback on it.
>
> Regarding the former, we understand the pain. Our use of shepherds is a way
> to tackle the problem. While it's not perfect it has definitely improved the
> situation IMO. As Jie mentioned earlier, if you have some other concrete
> suggestions to improve the process please join us in our community syncs and
> help us! We will be grateful. It is not an easy problem to solve.
>
> As an aside, I feel the tone of this thread has gone from being constructive
> to being attacking and personal. This is not acceptable in the Mesos
> community. Please refer to
> http://www.apache.org/foundation/policies/conduct.html for our code of
> conduct. This might be different from the Linux community.

This has conflicts with the previously paragraph.

I understand why you feel being attacked by just pointing out your mistakes.
Most human beings do, people don't like to admit their mistakes , me too!!!

The only difference is I always thank people who points out my mistakes
instead of feeling attacked.

This is exactly I don't like to join your community syncs. Your
reaction reflects
something deep in your culture (because you as a committer represents the
community), this is why this community can't be improved.

Think about it, Vinod. Remember that, the opposite of love is not hate,
it's indifference. If I really hated your community, I would just keep
silent here
and laugh at you in a different place. You should be smart enough to figure
out which way is helpful to improve your community.

I am _not_ saying my advice is valuable, I am just saying refusing to listen
hurts your community, especially when you consider pointing out your
mistakes as attacks.

Re: Backport r/44230 to 0.27 branch

Posted by Vinod Kone <vi...@apache.org>.
Cong, I understand your frustration with the review process and backports.
I've already created a ticket to track the latter. Would love your
input/feedback on it.

Regarding the former, we understand the pain. Our use of shepherds is a way
to tackle the problem. While it's not perfect it has definitely improved
the situation IMO. As Jie mentioned earlier, if you have some other
concrete suggestions to improve the process please join us in our community
syncs and help us! We will be grateful. It is not an easy problem to solve.

As an aside, I feel the tone of this thread has gone from being
constructive to being attacking and personal. This is not acceptable in the
Mesos community. Please refer to
http://www.apache.org/foundation/policies/conduct.html for our code of
conduct. This might be different from the Linux community.

On Wed, Mar 16, 2016 at 3:23 PM, Cong Wang <cw...@twopensource.com> wrote:

> On Wed, Mar 16, 2016 at 2:50 PM, Jie Yu <yu...@gmail.com> wrote:
> >>
> >> Why not check your backlog for your answer? Or do you need me to write
> >> a script to scan all the pending review requests for you?
> >
> >
> > OK, i just looked at your pending patches:
> > https://reviews.apache.org/users/wangcong/?show-closed=0
> >
> > The associated tickets:
> > https://issues.apache.org/jira/browse/MESOS-4740
> > https://issues.apache.org/jira/browse/MESOS-2769
> > https://issues.apache.org/jira/browse/MESOS-2799
> >
> > (Some of the rb request does not have associated tickets)
>
> Even your rb doesn't have one:
> https://reviews.apache.org/r/44922/
>
> Not to mention those commits don't even have a RB at all...
>
> https://github.com/apache/mesos/commit/19dd467500ea31371dbebe73a4acfa0346aa9e40
>
> https://github.com/apache/mesos/commit/8c83b843dfcd08f82a394c29939f3c5940a78027
>
> https://github.com/apache/mesos/commit/2de2e5791a6c119e26e9e0bc35bdea4b2e54bbec
>
> What's your point here?
>
>
> >
> > I don't see a shepherd for MESOS-4740. Looks like Vinod is the shepherd
> for
> > MESOS-2769. MESOS-2799 does not have shepherd as well, but I think that
> > should be me. Are you still interested in shipping those patches?
>
> Whether to ship my patches or not is a trivial problem to fix, the
> bigger problem,
> which you keep ignoring, is why this rule (shepherd, ping etc.) can't be
> improved?
>
>
> >
> > I think you made a valid point that there is some problem regarding:
> > 1) Do we want to work on all created tickets (i.e., how do we decide if
> we
> > want to accept a ticket or not), and who decide that?
>
> Why always need a ticket? Some big feature does need one to track
> the subtickets, I definitely agree, but for things like a typo fix
> apparently not.
>
> It doesn't worth the time at all to create a ticket when you just
> want to fix some indention like the one you did:
>
>
> https://github.com/apache/mesos/commit/19dd467500ea31371dbebe73a4acfa0346aa9e40
>
> (although I think this worth a RB).
>
>
> > 2) Once we accept the ticket, how can we prioritize those tickets? Should
> > PMC members groom the accepted tickets regularly?
>
> Why prioritize tickets rather than just reviews? Code is on review board
> not
> in tickets, you should be able to evaluate the code to decide if it is
> ready to
> merge or not. Linux kernel never uses tickets to track features, once
> all reviews
> are addresses it would be merged.
>
>
> > 3) If no committer is volunteer for the accepted ticket, what's the
> > procedure in that case, should we pick one?
> > 4) What's the procedure of finding another shepherd if the original
> > shepherd does not have time for that anymore.
>
>
> Promote new committers, seriously.
>
> You have 20+ committers, if all of you are working, you should be able to
> handle all the reviews. The problem is apparently some of you are not
> working, so why not promote new ones to replace non-working ones?
>

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 2:50 PM, Jie Yu <yu...@gmail.com> wrote:
>>
>> Why not check your backlog for your answer? Or do you need me to write
>> a script to scan all the pending review requests for you?
>
>
> OK, i just looked at your pending patches:
> https://reviews.apache.org/users/wangcong/?show-closed=0
>
> The associated tickets:
> https://issues.apache.org/jira/browse/MESOS-4740
> https://issues.apache.org/jira/browse/MESOS-2769
> https://issues.apache.org/jira/browse/MESOS-2799
>
> (Some of the rb request does not have associated tickets)

Even your rb doesn't have one:
https://reviews.apache.org/r/44922/

Not to mention those commits don't even have a RB at all...
https://github.com/apache/mesos/commit/19dd467500ea31371dbebe73a4acfa0346aa9e40
https://github.com/apache/mesos/commit/8c83b843dfcd08f82a394c29939f3c5940a78027
https://github.com/apache/mesos/commit/2de2e5791a6c119e26e9e0bc35bdea4b2e54bbec

What's your point here?


>
> I don't see a shepherd for MESOS-4740. Looks like Vinod is the shepherd for
> MESOS-2769. MESOS-2799 does not have shepherd as well, but I think that
> should be me. Are you still interested in shipping those patches?

Whether to ship my patches or not is a trivial problem to fix, the
bigger problem,
which you keep ignoring, is why this rule (shepherd, ping etc.) can't be
improved?


>
> I think you made a valid point that there is some problem regarding:
> 1) Do we want to work on all created tickets (i.e., how do we decide if we
> want to accept a ticket or not), and who decide that?

Why always need a ticket? Some big feature does need one to track
the subtickets, I definitely agree, but for things like a typo fix
apparently not.

It doesn't worth the time at all to create a ticket when you just
want to fix some indention like the one you did:

https://github.com/apache/mesos/commit/19dd467500ea31371dbebe73a4acfa0346aa9e40

(although I think this worth a RB).


> 2) Once we accept the ticket, how can we prioritize those tickets? Should
> PMC members groom the accepted tickets regularly?

Why prioritize tickets rather than just reviews? Code is on review board not
in tickets, you should be able to evaluate the code to decide if it is ready to
merge or not. Linux kernel never uses tickets to track features, once
all reviews
are addresses it would be merged.


> 3) If no committer is volunteer for the accepted ticket, what's the
> procedure in that case, should we pick one?
> 4) What's the procedure of finding another shepherd if the original
> shepherd does not have time for that anymore.


Promote new committers, seriously.

You have 20+ committers, if all of you are working, you should be able to
handle all the reviews. The problem is apparently some of you are not
working, so why not promote new ones to replace non-working ones?

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
>
> Why not check your backlog for your answer? Or do you need me to write
> a script to scan all the pending review requests for you?


OK, i just looked at your pending patches:
https://reviews.apache.org/users/wangcong/?show-closed=0

The associated tickets:
https://issues.apache.org/jira/browse/MESOS-4740
https://issues.apache.org/jira/browse/MESOS-2769
https://issues.apache.org/jira/browse/MESOS-2799

(Some of the rb request does not have associated tickets)

I don't see a shepherd for MESOS-4740. Looks like Vinod is the shepherd for
MESOS-2769. MESOS-2799 does not have shepherd as well, but I think that
should be me. Are you still interested in shipping those patches?

I think you made a valid point that there is some problem regarding:
1) Do we want to work on all created tickets (i.e., how do we decide if we
want to accept a ticket or not), and who decide that?
2) Once we accept the ticket, how can we prioritize those tickets? Should
PMC members groom the accepted tickets regularly?
3) If no committer is volunteer for the accepted ticket, what's the
procedure in that case, should we pick one?
4) What's the procedure of finding another shepherd if the original
shepherd does not have time for that anymore.

- Jie


On Wed, Mar 16, 2016 at 2:32 PM, Cong Wang <cw...@twopensource.com> wrote:

> On Wed, Mar 16, 2016 at 2:21 PM, Jie Yu <yu...@gmail.com> wrote:
> > I understand your frustration. I am curious what review/ticket are you
> > talking about, and who is the shepherd for your review/ticket?
>
>
> Why not check your backlog for your answer? Or do you need me to write
> a script to scan all the pending review requests for you?
>
>
> >
> > Mesos project has a clear guide how to contribute to the project, that's
> > what the community has agreed on:
> >
> >
> https://github.com/apache/mesos/blob/master/docs/submitting-a-patch.md#before-you-start-writing-code
> >
>
> I assume this doesn't apply to your committers, at least BenM:
>
> commit 152ac2b13916bcf2bb9e52accc4951c3ce5bfd76
> Author: Benjamin Mahler <bm...@apache.org>
> Date:   Sun Feb 21 14:22:07 2016 +0100
>
>     Log the shutdown duration in the executor driver.
>
> commit 1488f16d283f69b7dc96feaee91b04a09012ca4a
> Author: Benjamin Mahler <bm...@apache.org>
> Date:   Sat Feb 20 17:35:30 2016 +0100
>
>
>     Added TASK_KILLING to the API changes in the CHANGELOG.
>
>
> commit 978ccb5dd637f0e1577ecae1e21973f50429b04c
> Author: Benjamin Mahler <bm...@apache.org>
> Date:   Sat Feb 20 17:28:58 2016 +0100
>
>
>     Added docker executor tests for TASK_KILLING.
>
>
> commit ee86b13633a9469629dbd79681d0776b6020f76a
> Author: Benjamin Mahler <bm...@apache.org>
> Date:   Sat Feb 20 16:18:22 2016 +0100
>
>
>     Added command executor tests for TASK_KILLING.
>
>
> commit 25d303d8743b524c92627d48f7dfb7ac2a921ede
> Author: Benjamin Mahler <bm...@apache.org>
> Date:   Sat Feb 20 15:31:28 2016 +0100
>
>
>     Fixed health check process leak when shutdown is called without
> killTask.
>
>
>
> > "Find a shepherd to collaborate on your patch. A shepherd is a Mesos
> > committer that will work with you to give you feedback on your proposed
> > design, and to eventually commit your change into the Mesos source tree."
> >
>
> This doesn't work, and it needs to change. I already state my reason in the
> previous reply, which is just ignored, yeah, like many other requests.
>

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 2:21 PM, Jie Yu <yu...@gmail.com> wrote:
> I understand your frustration. I am curious what review/ticket are you
> talking about, and who is the shepherd for your review/ticket?


Why not check your backlog for your answer? Or do you need me to write
a script to scan all the pending review requests for you?


>
> Mesos project has a clear guide how to contribute to the project, that's
> what the community has agreed on:
>
> https://github.com/apache/mesos/blob/master/docs/submitting-a-patch.md#before-you-start-writing-code
>

I assume this doesn't apply to your committers, at least BenM:

commit 152ac2b13916bcf2bb9e52accc4951c3ce5bfd76
Author: Benjamin Mahler <bm...@apache.org>
Date:   Sun Feb 21 14:22:07 2016 +0100

    Log the shutdown duration in the executor driver.

commit 1488f16d283f69b7dc96feaee91b04a09012ca4a
Author: Benjamin Mahler <bm...@apache.org>
Date:   Sat Feb 20 17:35:30 2016 +0100


    Added TASK_KILLING to the API changes in the CHANGELOG.


commit 978ccb5dd637f0e1577ecae1e21973f50429b04c
Author: Benjamin Mahler <bm...@apache.org>
Date:   Sat Feb 20 17:28:58 2016 +0100


    Added docker executor tests for TASK_KILLING.


commit ee86b13633a9469629dbd79681d0776b6020f76a
Author: Benjamin Mahler <bm...@apache.org>
Date:   Sat Feb 20 16:18:22 2016 +0100


    Added command executor tests for TASK_KILLING.


commit 25d303d8743b524c92627d48f7dfb7ac2a921ede
Author: Benjamin Mahler <bm...@apache.org>
Date:   Sat Feb 20 15:31:28 2016 +0100


    Fixed health check process leak when shutdown is called without killTask.



> "Find a shepherd to collaborate on your patch. A shepherd is a Mesos
> committer that will work with you to give you feedback on your proposed
> design, and to eventually commit your change into the Mesos source tree."
>

This doesn't work, and it needs to change. I already state my reason in the
previous reply, which is just ignored, yeah, like many other requests.

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
I understand your frustration. I am curious what review/ticket are you
talking about, and who is the shepherd for your review/ticket?

Mesos project has a clear guide how to contribute to the project, that's
what the community has agreed on:

https://github.com/apache/mesos/blob/master/docs/submitting-a-patch.md#before-you-start-writing-code

"Find a shepherd to collaborate on your patch. A shepherd is a Mesos
committer that will work with you to give you feedback on your proposed
design, and to eventually commit your change into the Mesos source tree."

- Jie




On Wed, Mar 16, 2016 at 2:03 PM, Cong Wang <cw...@twopensource.com> wrote:

> On Wed, Mar 16, 2016 at 12:18 PM, Jie Yu <yu...@gmail.com> wrote:
> >>
> >> like many other review requests are burned or take
> >
> > 6+ months to merge
> >
> >
> > Have you reached out to any shepherd for that ticket/review?
> >
>
> This is exactly where it doesn't work.
>
> You, as qualified as a committer, need to do _your_ work, you have
> to prioritize all the review requests you get, take care of all of them.
> Why? Because you have them all, you should know which of them
> are more important than others therefore should be reviewed earlier
> than later. You can't wait for others to tell you, because you are a
> committer.
>
> Priorities are based on _your_ understanding of the code, rather than
> who you know better or who pings you more than others.
>
> You have 20+ committers, you should be able to handle all of these
> review requests, but apparently some of them are not working at all
> so some of them are overloaded. This is a problem you need to fix,
> rather than being ping'ed.
>

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 12:18 PM, Jie Yu <yu...@gmail.com> wrote:
>>
>> like many other review requests are burned or take
>
> 6+ months to merge
>
>
> Have you reached out to any shepherd for that ticket/review?
>

This is exactly where it doesn't work.

You, as qualified as a committer, need to do _your_ work, you have
to prioritize all the review requests you get, take care of all of them.
Why? Because you have them all, you should know which of them
are more important than others therefore should be reviewed earlier
than later. You can't wait for others to tell you, because you are a
committer.

Priorities are based on _your_ understanding of the code, rather than
who you know better or who pings you more than others.

You have 20+ committers, you should be able to handle all of these
review requests, but apparently some of them are not working at all
so some of them are overloaded. This is a problem you need to fix,
rather than being ping'ed.

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
>
> like many other review requests are burned or take

6+ months to merge


Have you reached out to any shepherd for that ticket/review?

- Jie

On Wed, Mar 16, 2016 at 12:11 PM, Cong Wang <cw...@twopensource.com> wrote:

> On Wed, Mar 16, 2016 at 11:58 AM, Jie Yu <yu...@gmail.com> wrote:
> >
> > Currently, it's based on request. We definitely need to improve this
> part.
>
>
> It simply doesn't work, like many other review requests are burned or take
> 6+ months to merge. I am sure you need to improve that too, but after
> watching Mesos community for months, I don't see any improvement yet.
>

Re: Backport r/44230 to 0.27 branch

Posted by Vinod Kone <vi...@apache.org>.
Formalizing Mesos release strategy and support is something that I've been
thinking about a lot lately. In my mind, this is a blocker for Mesos
reaching 1.0.

I've filed https://issues.apache.org/jira/browse/MESOS-4962 to track this
work and added it to our current sprint; hopefully I/we can come up with a
design doc before end of the next week. If you have any suggestions or
requirements please feel free to chime in on the ticket or reach out on the
mailing list.

Thanks,

On Wed, Mar 16, 2016 at 12:37 PM, Jie Yu <yu...@gmail.com> wrote:

> Zhitao, that's a fair point. Can you add an agenda item to the next
> community sync to discuss this? Thanks!
>
> - Jie
>
> On Wed, Mar 16, 2016 at 12:16 PM, Zhitao Li <zh...@gmail.com> wrote:
>
>> Maybe we can try to draft a formal guideline about when/how something
>> should be back ported, and making sure interested parties in the community
>> have chance to get their voices heard?
>>
>> I'm also interested in knowing how much work it generates when they cut
>> with back port releases, and how the community could help.
>>
>> On Wed, Mar 16, 2016 at 12:11 PM, Cong Wang <cw...@twopensource.com>
>> wrote:
>>
>> > On Wed, Mar 16, 2016 at 11:58 AM, Jie Yu <yu...@gmail.com> wrote:
>> > >
>> > > Currently, it's based on request. We definitely need to improve this
>> > part.
>> >
>> >
>> > It simply doesn't work, like many other review requests are burned or
>> take
>> > 6+ months to merge. I am sure you need to improve that too, but after
>> > watching Mesos community for months, I don't see any improvement yet.
>> >
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
Zhitao, that's a fair point. Can you add an agenda item to the next
community sync to discuss this? Thanks!

- Jie

On Wed, Mar 16, 2016 at 12:16 PM, Zhitao Li <zh...@gmail.com> wrote:

> Maybe we can try to draft a formal guideline about when/how something
> should be back ported, and making sure interested parties in the community
> have chance to get their voices heard?
>
> I'm also interested in knowing how much work it generates when they cut
> with back port releases, and how the community could help.
>
> On Wed, Mar 16, 2016 at 12:11 PM, Cong Wang <cw...@twopensource.com>
> wrote:
>
> > On Wed, Mar 16, 2016 at 11:58 AM, Jie Yu <yu...@gmail.com> wrote:
> > >
> > > Currently, it's based on request. We definitely need to improve this
> > part.
> >
> >
> > It simply doesn't work, like many other review requests are burned or
> take
> > 6+ months to merge. I am sure you need to improve that too, but after
> > watching Mesos community for months, I don't see any improvement yet.
> >
>
>
>
> --
> Cheers,
>
> Zhitao Li
>

Re: Backport r/44230 to 0.27 branch

Posted by Zhitao Li <zh...@gmail.com>.
Maybe we can try to draft a formal guideline about when/how something
should be back ported, and making sure interested parties in the community
have chance to get their voices heard?

I'm also interested in knowing how much work it generates when they cut
with back port releases, and how the community could help.

On Wed, Mar 16, 2016 at 12:11 PM, Cong Wang <cw...@twopensource.com> wrote:

> On Wed, Mar 16, 2016 at 11:58 AM, Jie Yu <yu...@gmail.com> wrote:
> >
> > Currently, it's based on request. We definitely need to improve this
> part.
>
>
> It simply doesn't work, like many other review requests are burned or take
> 6+ months to merge. I am sure you need to improve that too, but after
> watching Mesos community for months, I don't see any improvement yet.
>



-- 
Cheers,

Zhitao Li

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Wed, Mar 16, 2016 at 11:58 AM, Jie Yu <yu...@gmail.com> wrote:
>
> Currently, it's based on request. We definitely need to improve this part.


It simply doesn't work, like many other review requests are burned or take
6+ months to merge. I am sure you need to improve that too, but after
watching Mesos community for months, I don't see any improvement yet.

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
>
> You don't need LTS as kernel, even talking about short term stable releases
> like 0.27.2 (?), they look horrible too, I don't see any git tags or
> branches for
> these releases, just a tar ball?! Huh...


Jies-MacBook-Pro:mesos jie$ git tag | grep 0.27
0.27.0
0.27.0-rc1
0.27.0-rc2
0.27.1
0.27.1-rc1
0.27.2
0.27.2-rc1

What determines which patches need to backport for Mesos community?
> It doesn't look like every bug fix is evaluated and considered after they
> are merged into master branch.


Currently, it's based on request. We definitely need to improve this part.
Note that, Mesos is a fast moving project and is young. Comparing it to
Linux (20+ years) is not a fair comparison.

On Wed, Mar 16, 2016 at 11:44 AM, Cong Wang <cw...@twopensource.com> wrote:

> On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yu...@gmail.com> wrote:
> > Mesos currently has no notion of long term stable releases (i.e., LTS). I
> > think the consensus in the last community sync was to introduce LTS after
> > 1.0.
>
>
> You don't need LTS as kernel, even talking about short term stable releases
> like 0.27.2 (?), they look horrible too, I don't see any git tags or
> branches for
> these releases, just a tar ball?! Huh...
>
>
> >
> > 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
> > backport it.
>
>
> What determines which patches need to backport for Mesos community?
> It doesn't look like every bug fix is evaluated and considered after they
> are merged into master branch.
>
> >
> > I am OK with back porting it. Then the question is that whether we want
> to
> > backport it to other releases as well.
> >
>
> It should be backported to whichever releases it applies to and you
> support,
> I don't see Mesos community has such a procedure.
>

Re: Backport r/44230 to 0.27 branch

Posted by Cong Wang <cw...@twopensource.com>.
On Tue, Mar 15, 2016 at 2:39 PM, Jie Yu <yu...@gmail.com> wrote:
> Mesos currently has no notion of long term stable releases (i.e., LTS). I
> think the consensus in the last community sync was to introduce LTS after
> 1.0.


You don't need LTS as kernel, even talking about short term stable releases
like 0.27.2 (?), they look horrible too, I don't see any git tags or
branches for
these releases, just a tar ball?! Huh...


>
> 0.27.2 has already been released. Looks like we need 0.27.3 if we want to
> backport it.


What determines which patches need to backport for Mesos community?
It doesn't look like every bug fix is evaluated and considered after they
are merged into master branch.

>
> I am OK with back porting it. Then the question is that whether we want to
> backport it to other releases as well.
>

It should be backported to whichever releases it applies to and you support,
I don't see Mesos community has such a procedure.

Re: Backport r/44230 to 0.27 branch

Posted by Jie Yu <yu...@gmail.com>.
Mesos currently has no notion of long term stable releases (i.e., LTS). I
think the consensus in the last community sync was to introduce LTS after
1.0.

0.27.2 has already been released. Looks like we need 0.27.3 if we want to
backport it.

I am OK with back porting it. Then the question is that whether we want to
backport it to other releases as well.

- Jie

On Tue, Mar 15, 2016 at 11:45 AM, Cong Wang <cw...@twopensource.com> wrote:

> Hi, all
>
> I don't know what is the process to request for a backport for Mesos
> stable releases and how Mesos community cares about stable releases.
> But... please consider to backport the following patch to at least
> 0.27 branch:
>
> https://reviews.apache.org/r/44230/
>
> It fixes a bug in our production which causes GC failed to prune a
> directory.
>
> The backport should be very straightforward. Please let me know if I
> can help anything.
>
> BTW, for Linux kernel we evaluate every bug fix to make sure it is
> backported to the right stable releases.
>
> Thanks.
>