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: bto...@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 <dtant...@redhat.com> wrote: > On 11/23/2015 05:42 P > > From: Morgan Fainberg <morgan.fainb...@gmail.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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@redhat.com_ > <mailto:dtant...@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-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 >
__________________________________________________________________________ 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
