Several sites are using it so it must be pretty easy. Hama for one. On Mon, Sep 27, 2010 at 6:27 PM, Benson Margulies <bimargul...@gmail.com>wrote:
> 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. > >> > > >
