Open Stack

Good, wide ranging discussion.

From my point of view, this isn’t about trusting cores, rather (as was pointed out by others) ensuring people with different customer perspectives be part of the approval. Of course, you could argue they could have -1’d it anyway, but I think ensuring cross-company approval helps us overall, and so I’m comfortable and support with the existing approach.

Henry
> On 24 Nov 2015, at 09:06, Henry Nash <henry.nash at icloud.com> wrote:
> 
> Good, wide ranging discussion.
> 
> From my point of view, this isn’t about trusting cores, rather (as was pointed out by others) ensuring people with different customer perspectives be part of the approval. Of course, you could argue they could have -1’d it anyway, but I think ensuring cross-company approval helps us overall, and so I’m comfortable and support with the existing approach.
> 
> Henry
>> On 24 Nov 2015, at 05:55, Clint Byrum <clint at fewbar.com <mailto:clint at fewbar.com>> wrote:
>> 
>> Excerpts from Adam Young's message of 2015-11-23 20:21:47 -0800:
>>> On 11/23/2015 11:42 AM, Morgan Fainberg wrote:
>>>> Hi everyone,
>>>> 
>>>> This email is being written in the context of Keystone more than any 
>>>> other project but I strongly believe that other projects could benefit 
>>>> from a similar evaluation of the policy.
>>>> 
>>>> Most projects have a policy that prevents the following scenario (it 
>>>> is a social policy not enforced by code):
>>>> 
>>>> * Employee from Company A writes code
>>>> * Other Employee from Company A reviews code
>>>> * Third Employee from Company A reviews and approves code.
>>>> 
>>>> This policy has a lot of history as to why it was implemented. I am 
>>>> not going to dive into the depths of this history as that is the past 
>>>> and we should be looking forward. This type of policy is an actively 
>>>> distrustful policy. With exception of a few potentially bad actors 
>>>> (again, not going to point anyone out here), most of the folks in the 
>>>> community who have been given core status on a project are trusted to 
>>>> make good decisions about code and code quality. I would hope that 
>>>> any/all of the Cores would also standup to their management chain if 
>>>> they were asked to "just push code through" if they didn't sincerely 
>>>> think it was a positive addition to the code base.
>>>> 
>>>> Now within Keystone, we have a fair amount of diversity of core 
>>>> reviewers, but we each have our specialities and in some cases 
>>>> (notably KeystoneAuth and even KeystoneClient) getting the required 
>>>> diversity of reviews has significantly slowed/stagnated a number of 
>>>> reviews.
>>>> 
>>>> What I would like us to do is to move to a trustful policy. I can 
>>>> confidently say that company affiliation means very little to me when 
>>>> I was PTL and nominating someone for core. We should explore making a 
>>>> change to a trustful model, and allow for cores (regardless of company 
>>>> affiliation) review/approve code. I say this since we have clear steps 
>>>> to correct any abuses of this policy change.
>>>> 
>>>> With all that said, here is the proposal I would like to set forth:
>>>> 
>>>> 1. Code reviews still need 2x Core Reviewers (no change)
>>>> 2. Code can be developed by a member of the same company as both core 
>>>> reviewers (and approvers).
>>>> 3. If the trust that is being given via this new policy is violated, 
>>>> the code can [if needed], be reverted (we are using git here) and the 
>>>> actors in question can lose core status (PTL discretion) and the 
>>>> policy can be changed back to the "distrustful" model described above.
>>>> 
>>>> I hope that everyone weighs what it means within the community to 
>>>> start moving to a trusting-of-our-peers model. I think this would be a 
>>>> net win and I'm willing to bet that it will remove noticeable 
>>>> roadblocks [and even make it easier to have an organization work 
>>>> towards stability fixes when they have the resources dedicated to it].
>>>> 
>>>> Thanks for your time reading this.
>>> 
>>> So, having been one of the initial architects of said policy, I'd like 
>>> to reiterate what I felt at the time.  The policy is in place as much to 
>>> protect the individual contributors as the project.  If I was put in a 
>>> position where I had to review and approve a coworkers code changes, it 
>>> is is easier for me to push back on a belligerent manager to say "this 
>>> violates project policy."
>>> 
>>> But, even this is a more paranoid rationale than I feel now.  Each of us 
>>> has a perspective based on our customer base.   People make decisions 
>>> based on what they feel to be right, but right for a public cloud 
>>> provider and right for an Enterprise Software vendor will be different.  
>>> Getting a change reviewed by someone outside your organization is for 
>>> perspective.  Treat it as a brake against group think.
>>> 
>>> I know and trust all of the current Keystone core very well.  I have no 
>>> expectation that any of them would violate the policy, even given the 
>>> looser interpretation.
>>> 
>> 
>> Adam this has been enlightening. I'm not sure I would do things the same
>> way, but I do have a greater understanding now of why things are the way
>> they are, and I fully respect that it has worked out O-K thus far. Thanks.
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org <mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <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/20151124/4ac71914/attachment.html>