I didn't know about the Hadoop patch plugin until I read your message, and I didn't read your message until after I posted this new thread. If that is easily shoveled around to other projects then it probably does everything I am looking to do.
On Mon, Sep 27, 2010 at 8:47 PM, Ted Dunning <ted.dunn...@gmail.com> wrote: > How is this different from the Hadoop patch plugin? There, patches added to > JIRA are checked out and built with problems reported back to JIRA. > > On Mon, Sep 27, 2010 at 5:43 PM, Benson Margulies > <bimargul...@gmail.com>wrote: > >> 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. >> >
