Open Stack

On Tue, Nov 24, 2015 at 6:44 AM, Lance Bragstad <lbragstad at gmail.com> wrote:

> I think one of the benefits of the current model was touched on earlier by
> dstanek. If someone is working on something for their organization, they
> typically bounce ideas of others they work with closely. This tends to be
> people within the same organization. The groups developing the feature
> might miss different perspectives on solving that particular problem.
> Bringing in a fresh set of eyes from someone outside that organization can
> be a huge benefit for the overall product.
>
> I don't think that is the sole reason to keep the existing policy, but I
> do think it's a positive side-effect.
>
>
I would assert that this is a side effect of good development practices and
really has not a lot to do with the policy at this point. The policy
doesn't really enforce/drive this. The cores are ultimately the gate
keepers and should be encouraging the continued reviewing by parties not
affiliated with their organization. I don't believe changing this policy
will generally have a negative impact on the cross-team reviewing. Cores
are always can choose to defer (we do this in many cases) when reviewing as
well to encourage the cross org review/view-points.

So, yes these are all positive things outlined, I don't think we'd see a
significant change on these fronts with a well rounded core group (as we
have). Encouraging good development practices is far different than what
the not-same-affiliation-for-cores-as-comitter policy accomplishes. I would
like to refocus the discussion here back towards the policy itself rather
than side-effects that are really a result of a healthy and mature
development community.



> On Tue, Nov 24, 2015 at 6:31 AM, David Chadwick <d.w.chadwick at kent.ac.uk>
> wrote:
>
>> Spot on. This is exactly the point I was trying to make
>>
>> David
>>
>> On 24/11/2015 11:20, Dolph Mathews wrote:
>> > Scenarios I've been personally involved with where the
>> > "distrustful" model either did help or would have helped:
>> >
>> > - Employee is reprimanded by management for not positively reviewing &
>> > approving a coworkers patch.
>> >
>> > - A team of employees is pressured to land a feature with as fast as
>> > possible. Minimal community involvement means a faster path to "merged,"
>> > right?
>> >
>> > - A large group of reviewers from the author's organization repeatedly
>> > throwing *many* careless +1s at a single patch. (These happened to not
>> > be cores, but it's a related organizational behavior taken to an
>> extreme.)
>> >
>> > I can actually think of a few more specific examples, but they are
>> > already described by one of the above.
>> >
>> > It's not cores that I do not trust, its the organizations they operate
>> > within which I have learned not to trust.
>> >
>> > On Monday, November 23, 2015, 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
>> >
>> >
>> >
>> >
>> __________________________________________________________________________
>> > 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
>>
>
>
> __________________________________________________________________________
> 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/20151124/75283a06/attachment-0001.html>