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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev