<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 14, 2015 at 9:42 AM, Assaf Muller <span dir="ltr"><<a href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>Responses in-line.<br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery <span dir="ltr"><<a href="mailto:mestery@mestery.com" target="_blank">mestery@mestery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Thanks a lot for the reply! I think it raises some good points here<br>
that I would like to clarify with other team members. I don't think<br>
those should interface with the current nomination run, so I spin it<br>
into a separate thread.<br>
<br></blockquote><div><br></div></span><div>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.<br> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some comments inline.<br>
<br>
On 08/12/2015 07:16 PM, Kyle Mestery wrote:<br>
>> [1] <a href="http://stackalytics.com/report/contribution/neutron-group/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron-group/90</a><br>
><br>
><br>
> Shouldn't we use the link that shows neutron core repo<br>
> contributions only? I think this is the right one:<br>
><br>
> <a href="http://stackalytics.com/report/contribution/neutron/90" rel="noreferrer" target="_blank">http://stackalytics.com/report/contribution/neutron/90</a><br>
><br>
><br>
>> Sure, if you want to look at only the neutron repo. I tend to<br>
>> look at people across all of our repos, which you may or may not<br>
>> agree with. I<br>
<br>
Neutron-core gerrit group indeed always had a vague definition. It<br>
worked fine before when we had just neutron and python-neutronclient<br>
repositories [even though client expertise stands out somewhat of<br>
usual server oriented development we do in neutron repo].<br>
<br></blockquote><div><br></div></span><div>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.<br> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now, with successful tree split into neutron, neutron-*aas,<br>
networking-*, + having a separate repo for specs; now that neutron is<br>
really a meta-project (a big tent they say),<br>
<br></blockquote><div><br></div></span><div>Nope, it's the "Neutron Stadium", the "Big Tent" moniker was already taken, so we came up with our own. ;)<br> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it feels to me that leaving neutron-core group as a "meta-group" that<br>
includes everyone who makes significant positive impact in any of<br>
those repos is not optimal. <br></blockquote></span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div></span><div>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?</div></div></div></div></blockquote><div><br></div></div></div><div>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.</div><div><div class="h5"><div> </div></div></div></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div><span><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Having core team members that are judged solely on how they impact the<br>
core repo seems to me a better approach. Fostering more focused teams<br>
was one of the goals of tree splits, so I think we should take that<br>
gerrit advantage of having multiple repos more seriously.<br>
<br></blockquote><div><br></div></span><div>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.<br> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> also think that it's worth looking at the statement of what core<br>
>> reviewers do found here [1]. Particularly what common ideals all<br>
>> core reviewers across Neutron share. I'll copy them here:<br>
><br>
>> 1. They share responsibility in the project’s success. 2. They<br>
>> have made a long-term, recurring time investment to improve the<br>
>> project. 3. They spend their time doing what needs to be done to<br>
>> ensure the projects success, not necessarily what is the most<br>
>> interesting or fun.<br>
><br>
<br>
The list is indeed a great one, and a lot of us, including - if not<br>
especially! - me, sometimes lag on some of those points.<br>
<br></blockquote></span><div><br>:)<br> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But doesn't the section talk about the big neutron tent, while voting<br>
permissions are still per-repo?<br>
<br></blockquote><div><br></div></span><div>Yes, it does.<br><br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> Also, keep in mind how we nominate core reviewers now that we<br>
>> have a Lieutenant system [2].<br>
<br>
That raises another interesting point that bothers me for some time.<br>
The section refers multiple times to 'Neutron core reviewers from the<br>
Lieutenant’s area of focus', but it does not say anything about<br>
reviewers [that I call 'obsolete'] who got into the core team before<br>
we had subteams and Lieutenants. Should they even have a say in<br>
subteam nominations? Everytime a nomination is proposed, I don't know<br>
whether I am in the position to put +1/-1.<br>
<br>
So the wording could be clarified here once we understand what the<br>
intended rules should be here.<br>
<br></blockquote><div><br></div></span><div>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.<br> <br></div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>> Finally, it's worth all core reviewers having a look at what's<br>
>> expected of core reviewers here. [3] I should point out that the<br>
>> team is severely lacking in weekly meeting attendance at this<br>
>> point, but it's not a good thread to do that. Instead, I'll just<br>
>> point out what we as a team have codified as expectations for<br>
>> core reviewers.<br>
<br>
Not that it's in the core of the matter for the thread, but I wonder<br>
what reasonable attendance is, considering we have shifted schedule<br>
that makes some team meetings occur at time when you usually prepare<br>
to sleep or order yet another beer in a pub. Is participation once per<br>
two weeks resonable, or should core reviewers strive to make it every<br>
week?<br>
<br></blockquote><div><br></div></span><div>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.<br><br></div><div>Thanks for starting this thread, I look forward to replies from everyone as we continue this healthy debate!<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div>Kyle<br></div></font></span><div><div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
>> Thanks! Kyle<br>
><br>
>> [1]<br>
>> <a href="http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewers" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-reviewers.h<br>
tml#neutron-core-reviewers</a><br>
>><br>
>><br>
[2]<br>
>> <a href="http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-reviewers.h<br>
tml#adding-or-removing-core-reviewers</a><br>
>><br>
>><br>
[3]<br>
>> <a href="http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#neutron-core-reviewer-membership-expectations" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/neutron/policies/core-reviewers.h<br>
tml#neutron-core-reviewer-membership-expectations</a><br>
><br>
>><br>
> Ihar<br>
><br>
> ______________________________________________________________________<br>
____<br>
><br>
><br>
OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
><br>
><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> ______________________________________________________________________<br>
____<br>
><br>
><br>
OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2<br>
<br>
iQEcBAEBCAAGBQJVzdD/AAoJEC5aWaUY1u57SHsH/2/oBqY4uJnfJxKnHI909mCn<br>
ttHu5j+Nvs7idb4opJm48UaHPcEGEea9ruzMz+usUtGY/vyYRhZ7svAENmAxKszR<br>
+d9Wkt0sxImpoCWkIEE7zS+EJNSxe+ps6F8vOpNnQO8RwuEOveQ0QXj85xgIToza<br>
LkFQiQUO+y4FIO0auXii/yAwwvj3euj+u2Q6oB1QnqVe+Mwf3xEnOrx5NPj4eLQ/<br>
sA2vLZcAx1cDVQORqum7ZSYr5Xm799bhDNmGfCFSShQ3znar4At4MHqDn8jW0rFZ<br>
w3Wy9QVdr0QaY4xxSj1ktRh0SXbFGVD2pPCPPm4m/myJ3o5mnknhYe2mUiRLh88=<br>
=UJ1E<br>
-----END PGP SIGNATURE-----<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div><br></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div></div></div><br></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>