Open Stack

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.



>
> Regards,
> --Morgan
> PTL Emeritus, Keystone
>
>
> __________________________________________________________________________
> 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/20151123/db7e39aa/attachment.html>