can't the other tests/systems also pull the LP topic branch straight from LP for testing?<div>This would allow:</div><div>test system 1 to pull trunk, merge topic branch A and test. if success it passes it off to<br><div>
test system 2 to pull trunk, merge topic branch A and test, while</div><div>test system 1 moves on, pulls trunk, merges topic branch B and tests</div><div>and so forth that way test system 1 isn't waiting for test system 2 to finish using the test branch before it can move on to another branch. This allows all the test systems to be working independently on different branches.</div>
<div><br><div class="gmail_quote">On Thu, Feb 24, 2011 at 4:55 PM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That is how it works now, but if we need to run tests that are not<br>
on the tarmac machine, we need to push that local branch somewhere<br>
so other things can test the same thing.<br>
<br>
Monty Taylor will have a much better idea of how to orchestrate all<br>
of this, I'm going off what we did in the past, and I know things<br>
have changed some since then.<br>
<font color="#888888"><br>
-Eric<br>
</font><div><div></div><div class="h5"><br>
On Thu, Feb 24, 2011 at 04:46:28PM -0600, Trey Morris wrote:<br>
>    yikes! i assumed tarmac was running things locally merged with trunk to<br>
>    test and actually merging after success. That's surprising. The branches<br>
>    would definitely be safer.<br>
><br>
>    On Thu, Feb 24, 2011 at 4:41 PM, Eric Day <<a href="mailto:eday@oddments.org">eday@oddments.org</a>> wrote:<br>
><br>
>      Yup. Right now when a <project>-core member clicks 'Approve'<br>
>      after code review, tarmac picks it up and pushes to trunk assuming<br>
>      unittests pass. Instead it could push to staging and trigger a hook<br>
>      in jenkins which would fire off a bunch of other jobs that run the<br>
>      staging branch through a battery of tests. If they all check out ok<br>
>      (possibly a human check in there to make sure variable results like<br>
>      performance testing are ok), staging gets pushed to the real trunk.<br>
>      -Eric<br>
>      On Thu, Feb 24, 2011 at 04:36:16PM -0600, Trey Morris wrote:<br>
>      >    I see. So their use would in general be for the use of automated<br>
>      systems?<br>
>      ><br>
>      >    On Thu, Feb 24, 2011 at 4:33 PM, Eric Day <<a href="mailto:eday@oddments.org">eday@oddments.org</a>><br>
>      wrote:<br>
>      ><br>
>      >      The extra branches are just an implementation detail, we can have<br>
>      >      them or not. It's really a matter of if it's possible and/or<br>
>      easier<br>
>      >      to have jenkins fire off new jobs with arbitrary branches that<br>
>      need<br>
>      >      to be merged with trunk for each job vs merging and pushing to a<br>
>      >      staging branch and have the jobs test that. Either way, we get<br>
>      the<br>
>      >      same result. We will also have the flexibility to test arbitrary<br>
>      >      branches before proposing either way. These extra "trunks" will<br>
>      not<br>
>      >      need to be managed, as tarmac/jenkins will control them.<br>
>      >      -Eric<br>
>      >      On Thu, Feb 24, 2011 at 04:24:11PM -0600, Trey Morris wrote:<br>
>      >      >    I'm curious what the point of having a line of trunks for a<br>
>      commit<br>
>      >      to<br>
>      >      >    bounce down on its way to trunk would gain us other than<br>
>      having to<br>
>      >      manage<br>
>      >      >    a line of trunks. What's wrong with status quo branch<br>
>      management<br>
>      >      (other<br>
>      >      >    than tests)? What's wrong with having the commit sit in its<br>
>      LP<br>
>      >      topic<br>
>      >      >    branch, which is every bit as publicly accessible as any<br>
>      branch in<br>
>      >      the<br>
>      >      >    line of trunks would be? The test system (or anyone who<br>
>      wants to<br>
>      >      play with<br>
>      >      >    it) can just grab trunk merge the topic branch and run<br>
>      however many<br>
>      >      levels<br>
>      >      >    or types of tests we deem appropriate. Success = trunk. Fail<br>
>      = test<br>
>      >      fail<br>
>      >      >    status in the test report.<br>
>      >      ><br>
>      >      >    On Thu, Feb 24, 2011 at 3:39 PM, Jay Pipes<br>
>      <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>><br>
>      >      wrote:<br>
>      >      ><br>
>      >      >      On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger<br>
>      >      >      <<a href="mailto:mark.washenberger@rackspace.com">mark.washenberger@rackspace.com</a>> wrote:<br>
>      >      >      >> This is what we're working on, and what Justin is<br>
>      proposing,<br>
>      >      Mark.<br>
>      >      >      >><br>
>      >      >      >> Basically, in Drizzle-land, people propose a merge into<br>
>      trunk,<br>
>      >      Hudson<br>
>      >      >      >> picks up that proposal, pulls the brnach into<br>
>      >      lp:drizzle/staging,<br>
>      >      >      >> builds Drizzle on all supported platforms (>12<br>
>      OS/distro<br>
>      >      combos),<br>
>      >      >      then<br>
>      >      >      >> runs all automated regression testing against the<br>
>      proposed<br>
>      >      branch<br>
>      >      >      (can<br>
>      >      >      >> take 3 or more hours).<br>
>      >      >      >><br>
>      >      >      >> We're proposing the same kind of automation for<br>
>      OpenStack.<br>
>      >      >      ><br>
>      >      >      > Sorry, I misunderstood what Justin was proposing. This<br>
>      sounds<br>
>      >      good to<br>
>      >      >      me.<br>
>      >      >      ><br>
>      >      >      > We could also do this without a staging branch by having<br>
>      the<br>
>      >      automated<br>
>      >      >      system check out trunk and merge the proposed branch<br>
>      locally.<br>
>      >      ><br>
>      >      >      Sure, this is, of course, quite possible, too :)<br>
>      >      ><br>
>      >      >      One thing that a staging-first branch allows, though, is<br>
>      to set<br>
>      >      up an<br>
>      >      >      environment where some *very* minor or style-only type<br>
>      commits<br>
>      >      can be<br>
>      >      >      fed into trunk directly without having to got through the<br>
>      full<br>
>      >      testing<br>
>      >      >      loop...<br>
>      >      >      -jay<br>
>      >      >      _______________________________________________<br>
>      >      >      Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>      >      >      Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>      >      >      Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>      >      >      More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>      ><br>
>      >      > _______________________________________________<br>
>      >      > Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>      >      > Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>      >      > Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>      >      > More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div></div>