[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:03:39 UTC 2015
On Fri, Aug 14, 2015 at 9:42 AM, Assaf Muller <amuller at redhat.com> 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:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA256
>>>
>>> Thanks a lot for the reply! I think it raises some good points here
>>> that I would like to clarify with other team members. I don't think
>>> those should interface with the current nomination run, so I spin it
>>> into a separate thread.
>>>
>>>
>> Absolutely! I think it's super healthy to have these discussions, it's
>> what healthy open source communities do. I'll answer your specific concerns
>> below.
>>
>>
>>> Some comments inline.
>>>
>>> On 08/12/2015 07:16 PM, Kyle Mestery wrote:
>>> >> [1] http://stackalytics.com/report/contribution/neutron-group/90
>>> >
>>> >
>>> > Shouldn't we use the link that shows neutron core repo
>>> > contributions only? I think this is the right one:
>>> >
>>> > http://stackalytics.com/report/contribution/neutron/90
>>> >
>>> >
>>> >> Sure, if you want to look at only the neutron repo. I tend to
>>> >> look at people across all of our repos, which you may or may not
>>> >> agree with. I
>>>
>>> Neutron-core gerrit group indeed always had a vague definition. It
>>> worked fine before when we had just neutron and python-neutronclient
>>> repositories [even though client expertise stands out somewhat of
>>> usual server oriented development we do in neutron repo].
>>>
>>>
>> Agreed. And on that note, I think it may make sense to separate out
>> client merge responsibilities from server ones, as there are typically
>> hardly any core reviewers for neutron who pay attention to the client at
>> this point.
>>
>>
>>> Now, with successful tree split into neutron, neutron-*aas,
>>> networking-*, + having a separate repo for specs; now that neutron is
>>> really a meta-project (a big tent they say),
>>>
>>>
>> Nope, it's the "Neutron Stadium", the "Big Tent" moniker was already
>> taken, so we came up with our own. ;)
>>
>>
>>> 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'd argue the system is built on a web of trust. If you trust me, and I
trust Russell and Brandon, then you should likely trust Russell and Brandon
as well. This is EXACTLY what the Lieutenant system was meant to convey,
though I now feel like perhaps people missed this key ingredient of the new
world we find ourselves in.
> I trust both of them to merge code, they have both proven it in other
>> Neutron projects (Brandon) and other OpenStack project (Russell). A month
>> of collecting meaningless stats doesn't help anyone. Further, if either of
>> them takes advantage of their merge responsibilities in anyway, we'll
>> remove them. We're a community that is self governed and built on trust and
>> integrity, breaching that will lead to extreme measures.
>>
>>
>>> Having core team members that are judged solely on how they impact the
>>> core repo seems to me a better approach. Fostering more focused teams
>>> was one of the goals of tree splits, so I think we should take that
>>> gerrit advantage of having multiple repos more seriously.
>>>
>>>
>> I'm not disagreeing with you here, but to your point below about "areas
>> of focus", it's harder than it looks. We're working within the confines of
>> the tools we have. I'm not saying you're incorrect in your assumption here
>> at all. Going back to Russell and Brandon, if they don't start reviewing at
>> a decent pace, we should remove their merge capabilities, as we should any
>> core who doesn't review.
>>
>>
>>> >> also think that it's worth looking at the statement of what core
>>> >> reviewers do found here [1]. Particularly what common ideals all
>>> >> core reviewers across Neutron share. I'll copy them here:
>>> >
>>> >> 1. They share responsibility in the project’s success. 2. They
>>> >> have made a long-term, recurring time investment to improve the
>>> >> project. 3. They spend their time doing what needs to be done to
>>> >> ensure the projects success, not necessarily what is the most
>>> >> interesting or fun.
>>> >
>>>
>>> The list is indeed a great one, and a lot of us, including - if not
>>> especially! - me, sometimes lag on some of those points.
>>>
>>>
>> :)
>>
>>
>>> But doesn't the section talk about the big neutron tent, while voting
>>> permissions are still per-repo?
>>>
>>>
>> Yes, it does.
>>
>> >> Also, keep in mind how we nominate core reviewers now that we
>>> >> have a Lieutenant system [2].
>>>
>>> That raises another interesting point that bothers me for some time.
>>> The section refers multiple times to 'Neutron core reviewers from the
>>> Lieutenant’s area of focus', but it does not say anything about
>>> reviewers [that I call 'obsolete'] who got into the core team before
>>> we had subteams and Lieutenants. Should they even have a say in
>>> subteam nominations? Everytime a nomination is proposed, I don't know
>>> whether I am in the position to put +1/-1.
>>>
>>> So the wording could be clarified here once we understand what the
>>> intended rules should be here.
>>>
>>>
>> In general, I want less rules. If I could do things over I'd wipe away
>> many of these rules and go with a system built solely on trust and
>> integrity, which is pretty much where we've landed. Have you noticed that
>> no one has gone and verified new cores are merging things only in their
>> area of focus? The reason for this is that I trust the Lieutenants, who
>> trust their new area of focus cores. If I or anyone else has to spend time
>> policing this stuff, the system is broken. We have to trust each other or
>> we've got nothing.
>>
>>
>>> >
>>> >> Finally, it's worth all core reviewers having a look at what's
>>> >> expected of core reviewers here. [3] I should point out that the
>>> >> team is severely lacking in weekly meeting attendance at this
>>> >> point, but it's not a good thread to do that. Instead, I'll just
>>> >> point out what we as a team have codified as expectations for
>>> >> core reviewers.
>>>
>>> Not that it's in the core of the matter for the thread, but I wonder
>>> what reasonable attendance is, considering we have shifted schedule
>>> that makes some team meetings occur at time when you usually prepare
>>> to sleep or order yet another beer in a pub. Is participation once per
>>> two weeks resonable, or should core reviewers strive to make it every
>>> week?
>>>
>>>
>> This is a cop out I'm afraid. The meeting has been rotating for quite a
>> while now, and I'm severely disappointed by the complete lack of attendance
>> by 75% of the core reviewers in Neutron. It could be that I'm getting tired
>> of running a meeting where the participation by people vested in the
>> project is very low, and maybe we should just stop having a meeting and
>> move to mailing list updates every week. I'm not going to police this, but
>> I find it hard to believe most core reviewers can stay up to date with the
>> happenings in Neutron by not attending and participating in this meeting
>> every week.
>>
>> Thanks for starting this thread, I look forward to replies from everyone
>> as we continue this healthy debate!
>>
>> Kyle
>>
>>
>>> >
>>> >> Thanks! Kyle
>>> >
>>> >> [1]
>>> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h
>>> tml#neutron-core-reviewers
>>> <http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewers>
>>> >>
>>> >>
>>> [2]
>>> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h
>>> tml#adding-or-removing-core-reviewers
>>> <http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers>
>>> >>
>>> >>
>>> [3]
>>> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h
>>> tml#neutron-core-reviewer-membership-expectations
>>> <http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewer-membership-expectations>
>>> >
>>> >>
>>> > Ihar
>>> >
>>> > ______________________________________________________________________
>>> ____
>>> >
>>> >
>>> OpenStack Development Mailing List (not for usage questions)
>>> > Unsubscribe:
>>> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> > <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>> >
>>> >
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>> >
>>> >
>>> >
>>> > ______________________________________________________________________
>>> ____
>>> >
>>> >
>>> 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
>>> >
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBCAAGBQJVzdD/AAoJEC5aWaUY1u57SHsH/2/oBqY4uJnfJxKnHI909mCn
>>> ttHu5j+Nvs7idb4opJm48UaHPcEGEea9ruzMz+usUtGY/vyYRhZ7svAENmAxKszR
>>> +d9Wkt0sxImpoCWkIEE7zS+EJNSxe+ps6F8vOpNnQO8RwuEOveQ0QXj85xgIToza
>>> LkFQiQUO+y4FIO0auXii/yAwwvj3euj+u2Q6oB1QnqVe+Mwf3xEnOrx5NPj4eLQ/
>>> sA2vLZcAx1cDVQORqum7ZSYr5Xm799bhDNmGfCFSShQ3znar4At4MHqDn8jW0rFZ
>>> w3Wy9QVdr0QaY4xxSj1ktRh0SXbFGVD2pPCPPm4m/myJ3o5mnknhYe2mUiRLh88=
>>> =UJ1E
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/b3c94715/attachment.html>
More information about the OpenStack-dev
mailing list