In some 'day job' environments I've worked in, the infrastructure included a 'pre-flight' automated build option. I think it would be valuable to add this to the ASF infrastructure, at least for the Java side of the Universe (where I see a relatively easy way to do it).
What's that? A way to ask a build server to apply a patch and run a full build. The most extreme version of this scheme is one in which a patch must pass a pre-flight test before it is committed to source control. That's not my proposal. Rather, I'm looking for a way to use shared servers to run lengthy test suites before the commit. Why would someone like to do this? As soon as I commit to the trunk, other developers are prone to pull down my changes and be inconvenienced if I made a mistake. On the other hand, I've only got so much computer available for testing ASF changes, so I'd like to be able to do more extensive testing on an ASF hudson instance. Also, some things have to be qualified against multiple JVMs. My personal macbook, for example, can't easily test with 1.5, since Apple flushed the 1.5 JVM from SnowLeopard. Could I do something like this with existing facilities? Yes, I could. I could make a sandbox branch, and a hudson job to build it. However, that does not scale so well to many other people doing the same thing, and I personally find it inelegant. What 'infra' would it take to make this fly? The existing infrastructure is actually very close to this. Consider the git mirrors at git.apache.org. If committers were permitted to create branches on there, and if committers were permitted to use the hudson web service API to create one-time jobs, and if the hudson git plugin were installed, then any committer (or any committer filtered by their PMC) could push a change to a git server and start a hudson job to build it. The purpose of this email is to measure interest / sympathy in this idea. If everyone else things it's pointless, I'm not about to go on a campaign to drum up support.
