Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <20130308203603.GH98093@USLT-205755.sungardas.corp>
References: 
 <B1DF26ECC0458748AC97CECE2DA98D41013175649781@SJCPMAILBOX01.citrite.net>
 <20130308162737.GC70639@USLT-205755.sungardas.corp>
 <CAKprHVZftnTbm5fSzAwDmtg8D75=jejvffG-_9Fet+giBad9Pg@mail.gmail.com>
 <B1DF26ECC0458748AC97CECE2DA98D41013175C60AAE@SJCPMAILBOX01.citrite.net>
 <20130308193027.GB94334@USLT-205755.sungardas.corp>
 <CAKprHVaOSQ8u9BLHS5BWCxfChXWUrOMZZ6a4b3TwtDVS0h3ckA@mail.gmail.com>
 <20130308203603.GH98093@USLT-205755.sungardas.corp>
From: David Nalley <david@gnsa.us>
Date: Fri, 8 Mar 2013 15:45:56 -0500
Message-ID: 
 <CAKprHVbBF103K+hagMs_LGBjnU_hzkuaki5W9eNR5EFPujQSag@mail.gmail.com>
Subject: Re: [PROPOSAL] BVT for CloudStack checkins
To: cloudstack-dev@incubator.apache.org
Cc: Alex Huang <Alex.Huang@citrix.com>
Content-Type: text/plain; charset=ISO-8859-1

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