Open Stack

Very sensible policy, Brad. Congrats to IBM for it

On 23/11/2015 21:38, Brad Topol wrote:
> Hi Morgan,
> 
> So lots of good points below. However I am pulled in two directions on
> this topic.
> 
> For small projects (e.g. pycadf, heat-translator) there are so few cores
> and the project is small in size that we as project cores permit two
> people from the same company as the code author to both +2 and then +A.
> On these projects we simply could not make progress if we did not have
> this trusting model.
> 
> For the larger projects like Cinder, the trusting model has led to
> trouble in the past. I have seen where if there was a piece of code
> where the following happens:
> 
>     * Employee from Company A writes code
>     * Other Employee from Company A reviews code
>     * Third Employee from Company A reviews and approves code.
> 
>     Then what can happen is the community looks at that code as Company
>     A's code not the community code. Thus when there are bugs in that
>     code they come back to company A and say "You put this code in all
>     by yourself, its buggy and you need to maintain it all by yourself".
>     If I was working for company B that seems like a pretty natural
>     reaction especially if it turns out the code requires lots of
>     maintenance. This was a real scenario and I was on the side (Company
>     A) getting the spanking from folks from a very irritated company B.
> 
> So to avoid the perception of a single company owning a piece of code,
> at IBM our policy for major projects like Cinder, Nova and currently
> many parts of Keystone (except pycadf) is to make sure we do not do the
> following for major OpenStack projects:
> 
>     * Employee from Company IBM writes code
>     * Other Employee from Company IBM reviews code
>     * Third Employee from Company IBM reviews and approves code.
> 
> Again for certain small projects we relax this rule. And certainly we
> could discuss relaxing this rule for larger portions of Keystone if
> needed. But as a general policy we strive to stick to the distrust model
> as much as we can as the "perception of impropriety" that exists with
> the trusting model can result in tangible headaches.
> 
> Thanks,
> 
> Brad
> 
> 
> Brad Topol, Ph.D.
> IBM Distinguished Engineer
> OpenStack
> (919) 543-0646
> Internet: btopol at us.ibm.com
> Assistant: Kendra Witherspoon (919) 254-0680
> 
> Inactive hide details for Morgan Fainberg ---11/23/2015 12:08:09 PM---On
> Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur <dtantsurMorgan Fainberg
> ---11/23/2015 12:08:09 PM---On Mon, Nov 23, 2015 at 8:51 AM, Dmitry
> Tantsur <dtantsur at redhat.com> wrote: > On 11/23/2015 05:42 P
> 
> From: Morgan Fainberg <morgan.fainberg at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Date: 11/23/2015 12:08 PM
> Subject: Re: [openstack-dev] [keystone][all] Move from active
> distrusting model to trusting model
> ------------------------------------------------------------------------
> 
> 
> 
> 
> 
> On Mon, Nov 23, 2015 at 8:51 AM, Dmitry Tantsur <_dtantsur at redhat.com_
> <mailto:dtantsur at redhat.com>> wrote:
> 
>     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.
> 
> 
> A change of this policy doesn't preclude reaching out for more view
> points, and that should always be done. This is part of trusting the
> cores to know when this is valuable. :) Thanks for joining the convo here!
>  
> 
> 
>     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_
>     _<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> __________________________________________________________________________
> 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
> 
> 
> 
> 
> 
> __________________________________________________________________________
> 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
>