On Fri, Mar 8, 2013 at 3:36 PM, Chip Childers <chip.child...@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.child...@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
