<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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><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><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><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><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><div>Nope, it's the "Neutron Stadium", the "Big Tent" moniker was already taken, so we came up with our own. ;)<br> <br></div><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>
<br></blockquote><div><br></div><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? 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><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><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><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><div><br>:)<br> <br></div><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><div>Yes, it does.<br><br></div><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><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><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><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!<br><br></div><div>Kyle<br></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.h
tml#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.h
tml#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.h
tml#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><br></div></div>