www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: preflight idea
Date Tue, 28 Sep 2010 01:27:41 GMT
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.dunning@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 <bimargulies@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.
>>
>

Mime
View raw message