<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Oct 11, 2013 at 12:43 PM, David Kranz <span dir="ltr"><<a href="mailto:dkranz@redhat.com" target="_blank">dkranz@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>On 10/11/2013 02:03 PM, Alessandro
      Pilotti wrote:<br>
    </div>
    </div><blockquote type="cite">
      
      <div><span><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px">
            <div style="word-wrap:break-word">
              <br>
            </div>
          </span><br>
        </span><br>
      </div>
      <br>
      <div><div class="im">
        <div>On Oct 11, 2013, at 19:29 , Russell Bryant <<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></div>
        <div> wrote:</div>
        <br>
        </div><blockquote type="cite"><div class="im">On 10/11/2013 12:04 PM, John Griffith
          wrote:<br></div></blockquote></div></blockquote></div></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Umm... just to clarify the section below is NOT from my message.  :)</div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite"><div><blockquote type="cite"><div class="im">
          </div><blockquote type="cite"><br>
            [... snip ...]<br>
          </blockquote>
        </blockquote><div class="im">
        <div><br>
        </div>
        <div>Talking about new community involvements, newcomers are
          getting very frustrated to have to wait for weeks to get a
          meaningful review and I cannot blame them if they don't want
          to get involved anymore after the first patch!</div>
        <div>This makes appear public bureocracy here in eastern Europe
          a lightweight process in comparison! :-)</div>
        <div><br>
        </div>
        <div>Let me add another practical reason about why a separate
          OpenStack project would be a good idea:</div>
        <div><br>
        </div>
        <div>Anytime that we commit a driver specific patch, a lot of
          Tempests tests are executed on Libvirt and XenServer (for
          Icehouse those will be joined by another pack of CIs,
          including Hyper-V).</div>
        <div>On the jenkins side, we have to wait for regression tests
          that have nothing to do with the code that we are pushing.
          During the H3 push, this meant waiting for hours and hoping
          not to have to issue the 100th "recheck / revery bug xxx".</div>
        <div><br>
        </div>
        <div>A separate project would obviously include only the
          required tests and be definitely more lightweight, offloading
          quite some work from the SmokeStack / Jenkins job for
          everybody's happiness.</div>
        <div><br>
        </div>
        <br>
      </div></div>
    </blockquote>
    I'm glad you brought this up. There are two issues here, both
    discussed by the qe/infra groups and others at the Havana summit and
    after. <br>
    <br>
    How do you/we know which regression tests have nothing to do with
    the code changed in a particular patch? Or that the answer won't
    change tomorrow? The only way to do that is to assert dependencies
    and non-dependencies between components that will be used to decide
    which tests should be run for each patch. There was a lively
    discussion (with me taking your side initially) at the summit and it
    was decided that a generic "wasting resources" argument was not
    sufficient to introduce that fragility and so we would run the whole
    test suite as a gate on all projects. That decision was to be
    revisited if resources became a problem.<br>
    <br>
    As for the 100th recheck, that is a result of the recent
    introduction of parallel tempest runs before the Havana rush. It was
    decided that the benefit in throughput from drastically reduced gate
    job times outweighed the pain of potentially doing a lot of
    rechecks. For the most part the bugs being surfaced were real
    OpenStack bugs that were showing up due to the new "stress" of
    parallel test execution. This was a good thing, though certainly
    painful to all. With hindsight I'm not sure if that was the right
    decision or not.<br>
    <br>
    This is just an explanation of what has happened and why. There are
    obviously costs and benefits of being tightly bound to the project.<span class="HOEnZb"><font color="#888888"><br>
    <br>
     -David<br>
  </font></span></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>