Correct, no human would use them. On Thu, Feb 24, 2011 at 5:36 PM, Trey Morris <trey.mor...@rackspace.com> wrote: > I see. So their use would in general be for the use of automated systems? > > On Thu, Feb 24, 2011 at 4:33 PM, Eric Day <e...@oddments.org> wrote: >> >> The extra branches are just an implementation detail, we can have >> them or not. It's really a matter of if it's possible and/or easier >> to have jenkins fire off new jobs with arbitrary branches that need >> to be merged with trunk for each job vs merging and pushing to a >> staging branch and have the jobs test that. Either way, we get the >> same result. We will also have the flexibility to test arbitrary >> branches before proposing either way. These extra "trunks" will not >> need to be managed, as tarmac/jenkins will control them. >> >> -Eric >> >> On Thu, Feb 24, 2011 at 04:24:11PM -0600, Trey Morris wrote: >> > I'm curious what the point of having a line of trunks for a commit to >> > bounce down on its way to trunk would gain us other than having to >> > manage >> > a line of trunks. What's wrong with status quo branch management >> > (other >> > than tests)? What's wrong with having the commit sit in its LP topic >> > branch, which is every bit as publicly accessible as any branch in >> > the >> > line of trunks would be? The test system (or anyone who wants to play >> > with >> > it) can just grab trunk merge the topic branch and run however many >> > levels >> > or types of tests we deem appropriate. Success = trunk. Fail = test >> > fail >> > status in the test report. >> > >> > On Thu, Feb 24, 2011 at 3:39 PM, Jay Pipes <jaypi...@gmail.com> >> > wrote: >> > >> > On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger >> > <mark.washenber...@rackspace.com> wrote: >> > >> This is what we're working on, and what Justin is proposing, >> > Mark. >> > >> >> > >> Basically, in Drizzle-land, people propose a merge into trunk, >> > Hudson >> > >> picks up that proposal, pulls the brnach into >> > lp:drizzle/staging, >> > >> builds Drizzle on all supported platforms (>12 OS/distro >> > combos), >> > then >> > >> runs all automated regression testing against the proposed >> > branch >> > (can >> > >> take 3 or more hours). >> > >> >> > >> We're proposing the same kind of automation for OpenStack. >> > > >> > > Sorry, I misunderstood what Justin was proposing. This sounds >> > good to >> > me. >> > > >> > > We could also do this without a staging branch by having the >> > automated >> > system check out trunk and merge the proposed branch locally. >> > >> > Sure, this is, of course, quite possible, too :) >> > >> > One thing that a staging-first branch allows, though, is to set up >> > an >> > environment where some *very* minor or style-only type commits can >> > be >> > fed into trunk directly without having to got through the full >> > testing >> > loop... >> > -jay >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~openstack >> > Post to : openstack@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~openstack >> > More help : https://help.launchpad.net/ListHelp >> >> > _______________________________________________ >> > Mailing list: https://launchpad.net/~openstack >> > Post to : openstack@lists.launchpad.net >> > Unsubscribe : https://launchpad.net/~openstack >> > More help : https://help.launchpad.net/ListHelp >> > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
