Open Stack

On 11/23/2015 05:42 PM, 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.

Thanks for raising this. I always apply this policy in ironic not 
because I don't think we're trustful with my colleagues. The problem I'm 
trying to avoid is members of the same company having the same one-sided 
view on a problem.

>
> 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.

This is probably a fair use case for not applying this rule.

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