<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 24, 2015 at 6:44 AM, Lance Bragstad <span dir="ltr"><<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>I don't think that is the sole reason to keep the existing policy, but I do think it's a positive side-effect.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br></div></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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.<br> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 24, 2015 at 6:31 AM, David Chadwick <span dir="ltr"><<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Spot on. This is exactly the point I was trying to make<br>
<span><font color="#888888"><br>
David<br>
</font></span><span><br>
On 24/11/2015 11:20, Dolph Mathews wrote:<br>
> Scenarios I've been personally involved with where the<br>
> "distrustful" model either did help or would have helped:<br>
><br>
> - Employee is reprimanded by management for not positively reviewing &<br>
> approving a coworkers patch.<br>
><br>
> - A team of employees is pressured to land a feature with as fast as<br>
> possible. Minimal community involvement means a faster path to "merged,"<br>
> right?<br>
><br>
> - A large group of reviewers from the author's organization repeatedly<br>
> throwing *many* careless +1s at a single patch. (These happened to not<br>
> be cores, but it's a related organizational behavior taken to an extreme.)<br>
><br>
> I can actually think of a few more specific examples, but they are<br>
> already described by one of the above.<br>
><br>
> It's not cores that I do not trust, its the organizations they operate<br>
> within which I have learned not to trust.<br>
><br>
> On Monday, November 23, 2015, Morgan Fainberg <<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a><br>
</span><div><div>> <mailto:<a href="mailto:morgan.fainberg@gmail.com" target="_blank">morgan.fainberg@gmail.com</a>>> wrote:<br>
><br>
> Hi everyone,<br>
><br>
> This email is being written in the context of Keystone more than any<br>
> other project but I strongly believe that other projects could<br>
> benefit from a similar evaluation of the policy.<br>
><br>
> Most projects have a policy that prevents the following scenario (it<br>
> is a social policy not enforced by code):<br>
><br>
> * Employee from Company A writes code<br>
> * Other Employee from Company A reviews code<br>
> * Third Employee from Company A reviews and approves code.<br>
><br>
> This policy has a lot of history as to why it was implemented. I am<br>
> not going to dive into the depths of this history as that is the<br>
> past and we should be looking forward. This type of policy is an<br>
> actively distrustful policy. With exception of a few potentially bad<br>
> actors (again, not going to point anyone out here), most of the<br>
> folks in the community who have been given core status on a project<br>
> are trusted to make good decisions about code and code quality. I<br>
> would hope that any/all of the Cores would also standup to their<br>
> management chain if they were asked to "just push code through" if<br>
> they didn't sincerely think it was a positive addition to the code base.<br>
><br>
> Now within Keystone, we have a fair amount of diversity of core<br>
> reviewers, but we each have our specialities and in some cases<br>
> (notably KeystoneAuth and even KeystoneClient) getting the required<br>
> diversity of reviews has significantly slowed/stagnated a number of<br>
> reviews.<br>
><br>
> What I would like us to do is to move to a trustful policy. I can<br>
> confidently say that company affiliation means very little to me<br>
> when I was PTL and nominating someone for core. We should explore<br>
> making a change to a trustful model, and allow for cores (regardless<br>
> of company affiliation) review/approve code. I say this since we<br>
> have clear steps to correct any abuses of this policy change.<br>
><br>
> With all that said, here is the proposal I would like to set forth:<br>
><br>
> 1. Code reviews still need 2x Core Reviewers (no change)<br>
> 2. Code can be developed by a member of the same company as both<br>
> core reviewers (and approvers).<br>
> 3. If the trust that is being given via this new policy is violated,<br>
> the code can [if needed], be reverted (we are using git here) and<br>
> the actors in question can lose core status (PTL discretion) and the<br>
> policy can be changed back to the "distrustful" model described above.<br>
><br>
> I hope that everyone weighs what it means within the community to<br>
> start moving to a trusting-of-our-peers model. I think this would be<br>
> a net win and I'm willing to bet that it will remove noticeable<br>
> roadblocks [and even make it easier to have an organization work<br>
> towards stability fixes when they have the resources dedicated to it].<br>
><br>
> Thanks for your time reading this.<br>
><br>
> Regards,<br>
> --Morgan<br>
> PTL Emeritus, Keystone<br>
><br>
><br>
><br>
</div></div><div><div>> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>