Open Stack

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? 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
> >>
> >>
> [2]
> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h
> tml#adding-or-removing-core-reviewers
> >>
> >>
> [3]
> >> http://docs.openstack.org/developer/neutron/policies/core-reviewers.h
> tml#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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/31821e4f/attachment.html>