Open Stack

Since the ultimate arbiter is the PTL, then it would be wrong to allow
members of the same organisation as the PTL to perform all three code
functions without the input of anyone from any other organisation. This
places too much power in the hands of one organisation to the detriment
of the overall community.

David

On 23/11/2015 17:12, Matt Fischer wrote:
> On Mon, Nov 23, 2015 at 9:42 AM, Morgan Fainberg
> <morgan.fainberg at gmail.com <mailto:morgan.fainberg at 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
> 
> 
> 
> I happen to disagree with it in the general case. Developers, even cores
> or especially cores, can be subject to political and career pressure to
> get changes merged. Some employees are judged by managers on the number
> of commits/features they land. This puts pressure on them to push things
> through. I hope this is the exception, but I think it does happen. Part
> of being a core is wielding influence, soft power in other words; it's
> not unreasonable to expect a core reviewer to be able to get a +2 from
> someone outside their company. That's my opinion on the general case.  
> 
> In the specific case of a project like puppet-openstack, we are not a
> large team of reviewers and so although we generally try our best to
> avoid having +2s from the same company or merging each other's work, it
> does sometimes happen. We still strive to have at least one +2 from
> someone outside our company. So I think some projects are already doing
> this (we are) but it requires a strong PTL who is willing to call out
> abuse and an understanding amongst the cores about what the social
> policy is. 
> 
> So on a project-by-project basis I think rules may already be
> bent/modified by the teams. I'm not sure if they're codified anywhere
> other than just known as an expectation.
> 
> 
> __________________________________________________________________________
> 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
>