Open Stack

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.