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?
