[openstack-dev] [neutron] What does being a neutron-core member mean? [WAS: Re: [neutron] I am pleased to propose two new Neutron API/DB/RPC core reviewers!]
Kyle Mestery
mestery at mestery.com
Fri Aug 14 15:14:16 UTC 2015
On Fri, Aug 14, 2015 at 10:00 AM, Flavio Percoco <flavio at redhat.com> wrote:
> On 14/08/15 10:42 -0400, Assaf Muller wrote:
>
>> First I'd like to say that I recognize that this discussion is incredibly
>> personal. Brandon and Russell, please do not be offended, but I know that
>> I
>> probably would be if this very public thread involved myself. That being
>> said,
>> please know that from my perspective this is *not* personal, rather I see
>> this
>> as a general discussion about the precedent that we are creating here.
>>
>> Responses in-line.
>>
>> On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery <mestery at mestery.com>
>> wrote:
>>
>> On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka <ihrachys at redhat.com>
>> wrote:
>> it feels to me that leaving neutron-core group as a "meta-group"
>> that
>> includes everyone who makes significant positive impact in any of
>> those repos is not optimal.
>>
>> This is where I'd disagree. I think in general teams pay too much
>> attention
>> to stats, which are incredibly easy to game. Case in point, with the
>> current objections people have over Brandon and Russell being
>> nominated, I
>> could have waited 4-6 weeks and let them amass a plethora of review
>> stats,
>> but what would the point of that have been?
>>
>>
>> None what so ever. I think the point here is that if someone is focusing
>> on
>> another project then it's debatable if they should become a core in the
>> Neutron
>> project itself. Very simply put, if someone is a core in a subproject and
>> is
>> doing a fantastic job, but that person is not truly involved in the
>> Neutron
>> project itself, then that person becoming core in Neutron to me is
>> dangerous.
>> Before someone becomes core, I would like to be familiar with their
>> expertise
>> in Neutron so that I know if to trust their +2 or not on a given area in
>> Neutron. If that person didn't really focus on Neutron then I have no way
>> of
>> being familiar with their expertise, thus no ability to trust them even
>> if I'm
>> generally a trusting person.
>>
>
> I'm not really familiar with Neutron's workflow but as an outsider and
> also based on my experience from other projects, the separation of
> concerns from a review perspective is very useful. Teams that govern
> several projects are be better off giving reviewing rights to folks
> in a per-project basis rather than doing it cross-team.
>
> I'd go as far as saying that folks with review rights in the server
> don't necessarily need to have review rights in smaller projects. The
> reason I'm saying this is because I believe that reviewer rights is
> not a prize but a volunteer job. The moment I'm asked whether I want
> to join a reviewers team in a project, I gotta be honest with what my
> available time will allow me to do.
>
>
What you just said is what I've been trying to emphasize my entire time as
PTL: Reviewing is a duty, not a prize. The thing we're discussing here is
the issue of when to give someone +2 rights. I'm arguing in favor of a web
of trust system, which is what we have with Lieutenants. I'm also saying
that I'm a proponent of elevating folks who want to take on the duty and
letting them do that before they spend a month building up stats. This is
not an opinion shared by everyone I realize, but it's my opinion.
Like I've said in this thread, the entire system is built on trust. We as a
community need to trust more and rely on that trust. I feel as if I've
spent my PTL time trying to build that up and instill this value into the
Neutron community. The results speak for themselves at this point, but I'm
proud of what *we* as a community have built here.
Kyle
> To what I just said, I'd also add the familiarity with the code-base,
> etc.
>
> Just my $0.02,
> Flavio
>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/7bdea458/attachment.html>
More information about the OpenStack-dev
mailing list