MESOS-2516: Shepherd wanted

[José Guilherme Vanz <gu...@gmail.com>]

Hi everyone!

I'm looking for a shepherd to the issue MESOS-2516. I've already have the
preliminary patch in  my github mirror to send to review. However, I would
like to find the shepherd before send the code.

Someone volunteer? =]

Best
Vanz

Re: MESOS-2516: Shepherd wanted

[Alex Rukletsov <al...@mesosphere.com>]

José—

Thanks a lot for taking this and doing the cleanup! I have filed this
ticket some time ago, but currently I don't have cycles to shepherd. It
looks like other shepherds have different priorities right now and can't
help out here either. Right now most of shepherds are focusing on 0.29,
which we strive to ship before MesosCon NA.

We can work on this starting late-June. Hope you this is fine with you : ).

On Fri, May 13, 2016 at 7:45 PM, Cong Wang <cw...@twopensource.com> wrote:

> On Thu, May 12, 2016 at 8:54 PM, José Guilherme Vanz
> <gu...@gmail.com> wrote:
> > Even I did not find a shepherd, I've uploaded a first version of the
> patch
> > in the review board.
>
> You are not alone. This is the biggest problem of this community which
> people here refuse to see, especially when we are not in Mesospshere. ;)
>

Re: MESOS-2516: Shepherd wanted

[Vinod Kone <vi...@apache.org>]

Hi guys,

Thanks for bringing up the issues regarding getting patches/reviews
committed. Instead of answering specific questions or points raised in this
thread, I wanted to highlight some of the things we've done or doing (and
plan to do) to improve the process further.

*Re: Roadmap*: Perhaps this is not communicated as prominently as it
should've been, but we do have a roadmap doc (that will be reviewed/updated
during community syncs) on the wiki
<https://cwiki.apache.org/confluence/display/MESOS/%5BDRAFT%5D+Roadmap>.
I'll make sure to update the website to link to the roadmap so people can
find it more easily. The roadmap captures the current priorities of the
project and where most shepherds time is being spent on. There is nothing
opaque about this.

If you are newbie to the project, it would be best to pick work from the
roadmap items instead of something random. If you do so, there is a very
high chance that the shepherd of the roadmap item will be able to shepherd
your patch through. This is mainly because shepherds have limited bandwidth
to do reviews and working on something that they are already shepherding
will need fewer context switches for them. I've personally had success in
steering new contributors to work on items I'm already shepherding.

*Re: Triaging tickets/reviews: *One of the biggest pain points I've
observed (which was also pointed out in this thread) is that contributors
sometimes do not even get feedback on their patches. As a community and
PMC, we need to figure out how to improve this. From Mesosphere side, we've
begin instituting some processes to help alleviate some of this.  I do urge
committers that work for other companies to also chip in here.

*Re: Reviews: *Every person in the community should feel empowered to
review each other's patches if they feel have the context and knowledge. I
think shepherds will be thankful if contributors get reviews from
non-committers to suss out the low hanging fruit (typos, style etc). The
"credit" for doing so would be that you would be eventually recognized and
nominated to be a committer.

*Re: Committers: *I think it is clear that we need to add more committers
and groom them to be shepherds to better balance the reviewing workload.
The good news is that we have a few folks already in the pipeline that we
feel are ready to be committers! We will be nominating and voting them in
the next couple weeks.

*Re: Metrics: *While there is a visible section of the community that is
frustrated I believe we've improved (and continue to improve) the reviewing
process over time. We plan to gather and share metrics about how we are
doing in a continuous fashion (community syncs?) going forward.

Finally, I would like to point out that this is a team and community
effort.  No one company or organization is ultimately directly responsible.
In addition to recognizing and pointing problems, I would love for us to
come up with solutions. And by us, I mean everyone in the community, not
just the PMC. We will discuss some of these in our next community sync
(this thursday, 3 PM PST!), so please join.

Thanks,

On Mon, May 16, 2016 at 11:01 AM, Cong Wang <cw...@twopensource.com> wrote:

> Hello, Alex
>
> On Mon, May 16, 2016 at 10:17 AM, Alex Rukletsov <al...@mesosphere.com>
> wrote:
> > Cong,
> >
> > it's strange that you project your frustrations—which are understandable
> > and may have good reasons—on the project as a whole. There are reasons
> why
> > things are done in the way they are done; our primary goal is quality,
> we'd
> > rather have a few well implemented features rather than a bunch of
> > half-finished efforts that are hard to maintain. This means sometimes we
> > can't distract and invest time into some great but not yet prioritized
> > features.
>
> Sure, no one asks you to accept everything proposed, you always have
> the right to decline code you don't like, and this is clearly not what I am
> complaining.
>
> What I keep complaining is how fast you response to a review
> (no matter accept or decline), no one will be happy when his/her
> patch got no response after several months.
>
> And this is still happening in your community right now:
>
> https://reviews.apache.org/r/45605/
> https://reviews.apache.org/r/45606/
> https://reviews.apache.org/r/45607/
> https://reviews.apache.org/r/41302/
> https://reviews.apache.org/r/41305/
> https://reviews.apache.org/r/41306/
> https://reviews.apache.org/r/41308/
>
> (I can show you more as long as you need.)
>
> I am sure you will say I need to ping someone, clearly this doesn't work.
>
> >
> > You brought up some reasonable suggestions in other threads. As every
> group
> > of people with more that 1 person, Mesos community has some inertia.
> > Features, ideas, and processes should settle down and cook for a while
> > (except if it is a critical bug). It would be great if we can work
> together
> > improving developer experience, despite frustrations, inertia, and
> personal
> > opinions.
>
> I am glad to help, but people don't need my help.
>
> What progress do you make so far? Is there any new committer joining?
> Is there any non-working committers kicked out? Does any of you committers
> work more efficiently that before?
>
>
> >
> > But everyone can easily help us to deal with the known issues. Reviewing
> > patches of other contributors, paying attention to style and typos, do
> > better testing. All these things can be done right now, without
> discussion
> > and involving committers and will directly help them (committers) to feel
> > more comfortable about the feature and land patches. For example, you
> could
> > have reviewed r/47281/ and help José, right?
>
>
> Come on, even if I helped to review, so what? It is still there waiting for
> committers. Most of the times, committers are the bottleneck, not
> reviewers.
>
> On the other hand, what can I get if I help to review a patch? Will my name
> be shown in the git log? No. Will I get any real credit? No. So, why
> should I help to review? ;-P
>
> >
> > It would also help if we separate technical discussions from operational
> > issues. This way it's easier to search history.
> >
>
> This is all about your development process, not operations.
>
>
> > Though k8s is a great project, I don't think that hopping from project to
> > project is a rewarding experience. Like in a relationship, sometimes one
> > should invest time and effort to make things work. And be patient and
> > forgiving : ).
> >
>
> Sounds like you give yourself a reason to let people to wait for 6 months
> for their code to commit... Oh, well, I have been there:
>
> https://reviews.apache.org/r/38117/
>

Re: MESOS-2516: Shepherd wanted

[Cong Wang <cw...@twopensource.com>]

Hello, Alex

On Mon, May 16, 2016 at 10:17 AM, Alex Rukletsov <al...@mesosphere.com> wrote:
> Cong,
>
> it's strange that you project your frustrations—which are understandable
> and may have good reasons—on the project as a whole. There are reasons why
> things are done in the way they are done; our primary goal is quality, we'd
> rather have a few well implemented features rather than a bunch of
> half-finished efforts that are hard to maintain. This means sometimes we
> can't distract and invest time into some great but not yet prioritized
> features.

Sure, no one asks you to accept everything proposed, you always have
the right to decline code you don't like, and this is clearly not what I am
complaining.

What I keep complaining is how fast you response to a review
(no matter accept or decline), no one will be happy when his/her
patch got no response after several months.

And this is still happening in your community right now:

https://reviews.apache.org/r/45605/
https://reviews.apache.org/r/45606/
https://reviews.apache.org/r/45607/
https://reviews.apache.org/r/41302/
https://reviews.apache.org/r/41305/
https://reviews.apache.org/r/41306/
https://reviews.apache.org/r/41308/

(I can show you more as long as you need.)

I am sure you will say I need to ping someone, clearly this doesn't work.

>
> You brought up some reasonable suggestions in other threads. As every group
> of people with more that 1 person, Mesos community has some inertia.
> Features, ideas, and processes should settle down and cook for a while
> (except if it is a critical bug). It would be great if we can work together
> improving developer experience, despite frustrations, inertia, and personal
> opinions.

I am glad to help, but people don't need my help.

What progress do you make so far? Is there any new committer joining?
Is there any non-working committers kicked out? Does any of you committers
work more efficiently that before?


>
> But everyone can easily help us to deal with the known issues. Reviewing
> patches of other contributors, paying attention to style and typos, do
> better testing. All these things can be done right now, without discussion
> and involving committers and will directly help them (committers) to feel
> more comfortable about the feature and land patches. For example, you could
> have reviewed r/47281/ and help José, right?


Come on, even if I helped to review, so what? It is still there waiting for
committers. Most of the times, committers are the bottleneck, not reviewers.

On the other hand, what can I get if I help to review a patch? Will my name
be shown in the git log? No. Will I get any real credit? No. So, why
should I help to review? ;-P

>
> It would also help if we separate technical discussions from operational
> issues. This way it's easier to search history.
>

This is all about your development process, not operations.


> Though k8s is a great project, I don't think that hopping from project to
> project is a rewarding experience. Like in a relationship, sometimes one
> should invest time and effort to make things work. And be patient and
> forgiving : ).
>

Sounds like you give yourself a reason to let people to wait for 6 months
for their code to commit... Oh, well, I have been there:

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

Re: MESOS-2516: Shepherd wanted

[Abhishek Dasgupta <a1...@linux.vnet.ibm.com>]

Alex,
Very well said.:-)

On \u09b8\u09cb\u09ae\u09ac\u09be\u09b0 16 \u09ae\u09c7 2016 10:47 \u0985\u09aa\u09b0\u09be\u09b9\u09cd\u09a3, Alex Rukletsov wrote:
> Cong,
>
> it's strange that you project your frustrations\u2014which are understandable
> and may have good reasons\u2014on the project as a whole. There are reasons why
> things are done in the way they are done; our primary goal is quality, we'd
> rather have a few well implemented features rather than a bunch of
> half-finished efforts that are hard to maintain. This means sometimes we
> can't distract and invest time into some great but not yet prioritized
> features.
>
> You brought up some reasonable suggestions in other threads. As every group
> of people with more that 1 person, Mesos community has some inertia.
> Features, ideas, and processes should settle down and cook for a while
> (except if it is a critical bug). It would be great if we can work together
> improving developer experience, despite frustrations, inertia, and personal
> opinions.
>
> But everyone can easily help us to deal with the known issues. Reviewing
> patches of other contributors, paying attention to style and typos, do
> better testing. All these things can be done right now, without discussion
> and involving committers and will directly help them (committers) to feel
> more comfortable about the feature and land patches. For example, you could
> have reviewed r/47281/ and help Jos�, right?
>
> It would also help if we separate technical discussions from operational
> issues. This way it's easier to search history.
>
> Though k8s is a great project, I don't think that hopping from project to
> project is a rewarding experience. Like in a relationship, sometimes one
> should invest time and effort to make things work. And be patient and
> forgiving : ).
>
> On Mon, May 16, 2016 at 6:49 PM, Cong Wang <cw...@twopensource.com> wrote:
>
>> On Sat, May 14, 2016 at 12:22 PM, Jos� Guilherme Vanz
>> <gu...@gmail.com> wrote:
>>> If is always difficult to find I shepherd, change the approach can be a
>>> good ideia. Maybe remove this burocracy of a shepherd and keep just the
>>> review board and reviews. Once a new patch is uploaded the
>>> commiters/reviewers should review and give their feedback. All the
>> history
>>> will be in the Jira and review board.
>> Surely it is, people are just pretending to be blind...
>>
>> For a very quick example:
>> https://issues.apache.org/jira/browse/MESOS-4738
>>
>> I suggested the same, but as I expected nothing changes. I am quite
>> sure it will not change probably forever.
>>
>> Move to to work on something else, e.g. Kubernetes. ;)
>>

Re: MESOS-2516: Shepherd wanted

[Alex Rukletsov <al...@mesosphere.com>]

Cong,

it's strange that you project your frustrations—which are understandable
and may have good reasons—on the project as a whole. There are reasons why
things are done in the way they are done; our primary goal is quality, we'd
rather have a few well implemented features rather than a bunch of
half-finished efforts that are hard to maintain. This means sometimes we
can't distract and invest time into some great but not yet prioritized
features.

You brought up some reasonable suggestions in other threads. As every group
of people with more that 1 person, Mesos community has some inertia.
Features, ideas, and processes should settle down and cook for a while
(except if it is a critical bug). It would be great if we can work together
improving developer experience, despite frustrations, inertia, and personal
opinions.

But everyone can easily help us to deal with the known issues. Reviewing
patches of other contributors, paying attention to style and typos, do
better testing. All these things can be done right now, without discussion
and involving committers and will directly help them (committers) to feel
more comfortable about the feature and land patches. For example, you could
have reviewed r/47281/ and help José, right?

It would also help if we separate technical discussions from operational
issues. This way it's easier to search history.

Though k8s is a great project, I don't think that hopping from project to
project is a rewarding experience. Like in a relationship, sometimes one
should invest time and effort to make things work. And be patient and
forgiving : ).

On Mon, May 16, 2016 at 6:49 PM, Cong Wang <cw...@twopensource.com> wrote:

> On Sat, May 14, 2016 at 12:22 PM, José Guilherme Vanz
> <gu...@gmail.com> wrote:
> > If is always difficult to find I shepherd, change the approach can be a
> > good ideia. Maybe remove this burocracy of a shepherd and keep just the
> > review board and reviews. Once a new patch is uploaded the
> > commiters/reviewers should review and give their feedback. All the
> history
> > will be in the Jira and review board.
>
> Surely it is, people are just pretending to be blind...
>
> For a very quick example:
> https://issues.apache.org/jira/browse/MESOS-4738
>
> I suggested the same, but as I expected nothing changes. I am quite
> sure it will not change probably forever.
>
> Move to to work on something else, e.g. Kubernetes. ;)
>

Re: MESOS-2516: Shepherd wanted

[Cong Wang <cw...@twopensource.com>]

On Sat, May 14, 2016 at 12:22 PM, José Guilherme Vanz
<gu...@gmail.com> wrote:
> If is always difficult to find I shepherd, change the approach can be a
> good ideia. Maybe remove this burocracy of a shepherd and keep just the
> review board and reviews. Once a new patch is uploaded the
> commiters/reviewers should review and give their feedback. All the history
> will be in the Jira and review board.

Surely it is, people are just pretending to be blind...

For a very quick example:
https://issues.apache.org/jira/browse/MESOS-4738

I suggested the same, but as I expected nothing changes. I am quite
sure it will not change probably forever.

Move to to work on something else, e.g. Kubernetes. ;)

Re: MESOS-2516: Shepherd wanted

[Marco Massenzio <m....@gmail.com>]

On Sat, May 14, 2016 at 12:22 PM, José Guilherme Vanz <
guilherme.sft@gmail.com> wrote:

> I'm very new in the community and I do not know all the issues the
> community already faced. My advance apologies if I'm saying bullshit...
>
> If is always difficult to find I shepherd, change the approach can be a
> good ideia. Maybe remove this burocracy of a shepherd and keep just the
> review board and reviews.


​You would just remove the issue by one step, adding the frustration that
you have now invested the time in fixing the issue, but no one really cares
enough to give a review.
​


> Once a new patch is uploaded the
> commiters/reviewers should review and give their feedback. All the history
> will be in the Jira and review board.
>

​What you are saying is entirely correct and not b**t; but the issue is not
about "finding a shepherd," but rather around broadening community
participation and transparency around priorities.

Neither, paradoxically, seems to be a priority here - especially when 90%+
of committers now belong to the same commercial organization.
​
​AFAIK most of the organizations who use Mesos in Production now have their
own private forks, maintaining their own set of patches, which we can't get
committed upstream, for varied and, mostly, opaque reasons.  Needless to
say, it's a huge hassle​ and makes people wonder whether we'd be better off
with a different scheduler...


> On Fri, 13 May 2016 at 14:45 Cong Wang <cw...@twopensource.com> wrote:
>
> > On Thu, May 12, 2016 at 8:54 PM, José Guilherme Vanz
> > <gu...@gmail.com> wrote:
> > > Even I did not find a shepherd, I've uploaded a first version of the
> > patch
> > > in the review board.
> >
> > You are not alone. This is the biggest problem of this community which
> > people here refuse to see, especially when we are not in Mesospshere. ;)
> >
>

Re: MESOS-2516: Shepherd wanted

[José Guilherme Vanz <gu...@gmail.com>]

I'm very new in the community and I do not know all the issues the
community already faced. My advance apologies if I'm saying bullshit...

If is always difficult to find I shepherd, change the approach can be a
good ideia. Maybe remove this burocracy of a shepherd and keep just the
review board and reviews. Once a new patch is uploaded the
commiters/reviewers should review and give their feedback. All the history
will be in the Jira and review board.

On Fri, 13 May 2016 at 14:45 Cong Wang <cw...@twopensource.com> wrote:

> On Thu, May 12, 2016 at 8:54 PM, José Guilherme Vanz
> <gu...@gmail.com> wrote:
> > Even I did not find a shepherd, I've uploaded a first version of the
> patch
> > in the review board.
>
> You are not alone. This is the biggest problem of this community which
> people here refuse to see, especially when we are not in Mesospshere. ;)
>

Re: MESOS-2516: Shepherd wanted

[Cong Wang <cw...@twopensource.com>]

On Thu, May 12, 2016 at 8:54 PM, José Guilherme Vanz
<gu...@gmail.com> wrote:
> Even I did not find a shepherd, I've uploaded a first version of the patch
> in the review board.

You are not alone. This is the biggest problem of this community which
people here refuse to see, especially when we are not in Mesospshere. ;)

Re: MESOS-2516: Shepherd wanted

[José Guilherme Vanz <gu...@gmail.com>]

I've uploaded a new diff revision. The first revision has a build problem,
the revision 2 those problems are already solved.

Ok, after the review of the revision 2 I can send the email to the module
maillist.

On Sat, 14 May 2016 at 07:29 haosdent <ha...@gmail.com> wrote:

> It looks fine for me except for some minor style issues I left on it.
> Please add me as reviewers to trigger it pass jenkins build.
>
> In addition, I think need inform this to modules@mesos.apache.org and
> dev@mesos.apache.org in another thread.
> Because it change `mesos::master::allocator::Allocator` to
> `mesos::master::Allocator` in public interfaces, and affect those
>  third party allocator modules depends on this.
>
> On Fri, May 13, 2016 at 11:54 AM, José Guilherme Vanz <
> guilherme.sft@gmail.com> wrote:
>
> > Hi folks
> >
> > Even I did not find a shepherd, I've uploaded a first version of the
> patch
> > in the review board.
> >
> > Issue: https://issues.apache.org/jira/browse/MESOS-2516
> > Patch: https://reviews.apache.org/r/47281/
> >
> > Thanks!
> >
> > On Mon, 9 May 2016 at 22:39 José Guilherme Vanz <guilherme.sft@gmail.com
> >
> > wrote:
> >
> > > Hi everyone!
> > >
> > > I'm looking for a shepherd to the issue MESOS-2516. I've already have
> the
> > > preliminary patch in  my github mirror to send to review. However, I
> > would
> > > like to find the shepherd before send the code.
> > >
> > > Someone volunteer? =]
> > >
> > > Best
> > > Vanz
> > >
> >
>
>
>
> --
> Best Regards,
> Haosdent Huang
>

Re: MESOS-2516: Shepherd wanted

[haosdent <ha...@gmail.com>]

It looks fine for me except for some minor style issues I left on it.
Please add me as reviewers to trigger it pass jenkins build.

In addition, I think need inform this to modules@mesos.apache.org and
dev@mesos.apache.org in another thread.
Because it change `mesos::master::allocator::Allocator` to
`mesos::master::Allocator` in public interfaces, and affect those
 third party allocator modules depends on this.

On Fri, May 13, 2016 at 11:54 AM, José Guilherme Vanz <
guilherme.sft@gmail.com> wrote:

> Hi folks
>
> Even I did not find a shepherd, I've uploaded a first version of the patch
> in the review board.
>
> Issue: https://issues.apache.org/jira/browse/MESOS-2516
> Patch: https://reviews.apache.org/r/47281/
>
> Thanks!
>
> On Mon, 9 May 2016 at 22:39 José Guilherme Vanz <gu...@gmail.com>
> wrote:
>
> > Hi everyone!
> >
> > I'm looking for a shepherd to the issue MESOS-2516. I've already have the
> > preliminary patch in  my github mirror to send to review. However, I
> would
> > like to find the shepherd before send the code.
> >
> > Someone volunteer? =]
> >
> > Best
> > Vanz
> >
>



-- 
Best Regards,
Haosdent Huang

Re: MESOS-2516: Shepherd wanted

[José Guilherme Vanz <gu...@gmail.com>]

Hi folks

Even I did not find a shepherd, I've uploaded a first version of the patch
in the review board.

Issue: https://issues.apache.org/jira/browse/MESOS-2516
Patch: https://reviews.apache.org/r/47281/

Thanks!

On Mon, 9 May 2016 at 22:39 José Guilherme Vanz <gu...@gmail.com>
wrote:

> Hi everyone!
>
> I'm looking for a shepherd to the issue MESOS-2516. I've already have the
> preliminary patch in  my github mirror to send to review. However, I would
> like to find the shepherd before send the code.
>
> Someone volunteer? =]
>
> Best
> Vanz
>