Open Stack

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



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

__________________________________________________________________________
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/14e36906/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151123/14e36906/attachment.gif>