← Back to team overview

openstack team mailing list archive

Re: Should the OpenStack API re-use the EC2 credentials?

 

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
>
>

Follow ups

References