cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [PROPOSAL] BVT for CloudStack checkins
Date Fri, 08 Mar 2013 20:45:56 GMT
On Fri, Mar 8, 2013 at 3:36 PM, Chip Childers <chip.childers@sungard.com> wrote:
> 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?

We do on jenkins.cs.o...now. :)

No idea on builds.a.o - I am only a job admin not a jenkins admin.

--David

Mime
View raw message