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. >> > >> > >> > > We should also be prepared to discuss how other ASF projects deal with >> > > this, and how we are different from them (are we bigger, are we moving >> > > faster, etc...). >> > > >> > >> > >> > Honestly the Hadoop ecosystem has some of the same problems. It might be >> > worth talking with some of those folks. >> > >> > > So if we want to head down this path, which again I think we should >> > > (and I understand some of the concerns raised by others... we need to >> > > deal with those specific issues), then we need to bring the points >> > > above to a conclusion. >> > > >> > > Who wants to drive this discussion forward? >> > >> > The person who drives this, particularly with infrastructure, should be the >> > person who plans on doing the work to get this accomplished. In my mind >> > this is a medium term effort - probably a couple of months. >> >> I'm perfectly fine with driving the BVT side of things but like I said, I >> don't think I can do the infra side of things. Someone else needs to take >> that over. >> >> --Alex >> > > Well, if we want it someone needs to do it. I'm looking at hadoop (as > David suggested), and am willing to help craft the request to infra@. > We need one or two people to volunteer to implement / maintain any new > tool before we propose anything to the infra team. >
