Spot on. This is exactly the point I was trying to make David
On 24/11/2015 11:20, Dolph Mathews wrote: > Scenarios I've been personally involved with where the > "distrustful" model either did help or would have helped: > > - Employee is reprimanded by management for not positively reviewing & > approving a coworkers patch. > > - A team of employees is pressured to land a feature with as fast as > possible. Minimal community involvement means a faster path to "merged," > right? > > - A large group of reviewers from the author's organization repeatedly > throwing *many* careless +1s at a single patch. (These happened to not > be cores, but it's a related organizational behavior taken to an extreme.) > > I can actually think of a few more specific examples, but they are > already described by one of the above. > > It's not cores that I do not trust, its the organizations they operate > within which I have learned not to trust. > > On Monday, November 23, 2015, Morgan Fainberg <morgan.fainb...@gmail.com > <mailto:morgan.fainb...@gmail.com>> 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. > > Regards, > --Morgan > PTL Emeritus, Keystone > > > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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