cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [PROPOSAL] BVT for CloudStack checkins
Date Fri, 08 Mar 2013 20:36:03 GMT
On Fri, Mar 08, 2013 at 03:18:46PM -0500, David Nalley wrote:
> On Fri, Mar 8, 2013 at 2:30 PM, Chip Childers <chip.childers@sungard.com> wrote:
> > On Fri, Mar 08, 2013 at 08:54:05AM -0800, Alex Huang wrote:
> >> >
> >> > I'd add:
> >> > Large scale of our code base
> >> > Difficulty of testing at scale without plenty of hardware (which was a
problem
> >> > stated during incubation proposal)
> >>
> >> I'm going to start off a branch specifically to do BVT on  simulator and devCloud
so that we can at least have system vms/vrs and business logic tested.
> >>
> >> Specific hardware will be different but should be a much smaller part of our
code base.  Also I believe specific hardware code can be broken but mostly won't affect others.
 Here the main concern is changes impacting the developer community at large.
> >>
> >
> > I think that David is referring to the larger CI aspects of things.  If
> > we were to adopt gerrit, it would be best used (given Hugo's concerns)
> > as a gate into master (or x branches) after successful CI tests.  Hugo's
> > concern was that he not be blocked, waiting for another timezone to wake
> > up and review commits.
> >
> > IMO, our best path to success here is to have a couple of different
> > scenarios:
> >
> > 1 - Contributors (non-committers) submit a patch that will be tested
> > within a CI environment, but must also be reviewed / approved by at least one
> > committer, before being pushed into the repo.
> >
> > 2 - Committers submit a patch that will be tested within a CI
> > environment before being pushed into the repo.
> >
> > Optionally, committers need to be able to request that another reviewer
> > approve the patch before it's pushed (this helps with collaboration).
> >
> 
> Yes - I think this is essentially a CI problem to solve.
> 
> Let's not forget that we can already do this to a degree:
> http://olamy.blogspot.com/2012/10/test-your-local-patch-on-remote-jenkins.html
> 
> This allows us to use some of the test scenarios already setup for 4.1
> and master to test proposed patches. This isn't quite gerrit where
> it's all automated, but it's a step in the right direction.
> Though a BVT branch that mirrors master works too (though it will make
> commits noisy - essentially two messages for each commit) Perhaps
> olamy's above post to test proposed patches solves a problem.

Remind me again:  do we have the required Jenkins plugin installed on
either / both of builds.a.o and jenkins.cs.o?

Mime
View raw message