openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

Correct, no human would use them.

On Thu, Feb 24, 2011 at 5:36 PM, Trey Morris <trey.morris@xxxxxxxxxxxxx> 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 <eday@xxxxxxxxxxxx> 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 <jaypipes@xxxxxxxxx>
>> > wrote:
>> >
>> >      On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger
>> >      <mark.washenberger@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>> >      Unsubscribe : https://launchpad.net/~openstack
>> >      More help   : https://help.launchpad.net/ListHelp
>>
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~openstack
>> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~openstack
>> > More help   : https://help.launchpad.net/ListHelp
>>
>
>