<div dir="ltr">On 24 November 2015 at 06:21, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class=""><br></span>
    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></div></blockquote><div><br><br></div><div>I don't think cinder has ever formalised on this policy, and I don't necessarily think it should, but having it there as strong guidance is definitely useful in order to push back against internal management pressure when needed. It isn't a matter of trust, or even group think (though that can definitely be a problem) but one of giving developers (iin this case cores) the tools they need to push back against pressure inside their own companies.<br><br></div><div>In a similar vein, many well meaning and hard working engineers hit massive problems trying to get resources for CI until we started removing drivers from tree. Companies, particularly big ones, are slow moving, difficult to steer behemoths at times, and giving cores the tools to protect themselves, or devs more tools to help them get their job done, is definitely something we need to keep in mind.<br><br></div><div>Personally, my biggest indicator of a 'forced' review is time - if something has been open for two weeks with zero negative feedback, on an uncontentious topic, then I really don't care too much who approves it. If something lands in four hours during the European night on a topic that has been bounced around a lot on IRC/email then I get more worried, regardless of the organisation(s) of the cores who merged it. No amount of rules will fix that though, only discussion and trust of cores. Giving them a rule to stand behind when saying 'no' to their management chain is a great help though.<br></div><div> </div></div><div class="gmail_signature"><div dir="ltr"><div>-- <br>Duncan Thomas</div></div></div>
</div></div>