<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 11/23/2015 11:42 AM, Morgan Fainberg
wrote:<br>
</div>
<blockquote
cite="mid:CAGnj6au_e+YF9ie43_Tj0efkxA33wsPUJB99r41KYLRn8EgVYA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>Hi everyone,<br>
<br>
</div>
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.<br>
<br>
</div>
<div>Most projects have a policy that prevents the following
scenario (it is a social policy not enforced by code):<br>
<br>
</div>
<div>* Employee from Company A writes code<br>
</div>
<div>* Other Employee from Company A reviews code<br>
</div>
<div>* Third Employee from Company A reviews and approves code.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>With all that said, here is the proposal I would like to
set forth:<br>
<br>
</div>
<div>1. Code reviews still need 2x Core Reviewers (no change)<br>
</div>
<div>2. Code can be developed by a member of the same company as
both core reviewers (and approvers).<br>
</div>
<div>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.<br>
<br>
</div>
<div>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].<br>
<br>
</div>
<div>Thanks for your time reading this.<br>
</div>
</div>
</blockquote>
<br>
So, having been one of the initial architects of said policy, I'd
like to reiterate what I felt at the time. The policy is in place
as much to protect the individual contributors as the project. If I
was put in a position where I had to review and approve a coworkers
code changes, it is is easier for me to push back on a belligerent
manager to say "this violates project policy."<br>
<br>
But, even this is a more paranoid rationale than I feel now. Each
of us has a perspective based on our customer base. People make
decisions based on what they feel to be right, but right for a
public cloud provider and right for an Enterprise Software vendor
will be different. Getting a change reviewed by someone outside
your organization is for perspective. Treat it as a brake against
group think.<br>
<br>
I know and trust all of the current Keystone core very well. I have
no expectation that any of them would violate the policy, even given
the looser interpretation.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAGnj6au_e+YF9ie43_Tj0efkxA33wsPUJB99r41KYLRn8EgVYA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Regards,<br>
</div>
<div>--Morgan <br>
</div>
<div>PTL Emeritus, Keystone<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>