On Fri, Aug 14, 2015 at 9:42 AM, Assaf Muller <amul...@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 <mest...@mestery.com> wrote: > >> On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka <ihrac...@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-requ...@lists.openstack.org?subject:unsubscribe >>> > <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
