Open Stack

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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/d1b68cfd/attachment.html>