I ve just filed this jira for discussions about patch-testing. https://issues.apache.org/jira/browse/HADOOP-7003
Thanks, -Giri On Oct 20, 2010, at 1:30 PM, Nigel Daley wrote: > Thanks Giri. > >> Longterm solution: >> email patch process and queue creation is un-reliable. As a long term >> solution we need to use jira-cli command line tool to read patch directly >> from jira. > > Ya, that's what I've got mostly working on my machine. Any open Jira's for > this work? If not, I'll open one. > >> And doing this would require introducing a new workflow in jira. Apart from >> the current status called "patch-available" > > Not sure that's necessary. I think if we change the patch testing model a > little, we can keep the current workflow. Also, given some recent advances > in Hudson, I think we can reduce all the patch jobs down to 1 admin job > covering *all* projects and 1 job per project -- and we should be able to > drastically improve utilization of the slaves we have. Let's move this > discussion to a ticket. LMK if I need to open one. > > Cheers, > Nige > > On Oct 20, 2010, at 1:17 PM, Giridharan Kesavan wrote: > >> >> Old times: >> The hudson patch-testing admin job used to run on the master machine >> hudson.zones.apache.org as this machine used to parse the emails from jira >> and create the patch queue for testing. >> >> Current situation: >> hudson.zones.apache.org machine is no more a master and we have a new >> machine called aegis.apache.org as the master machine. >> >> This machine is configured to process the email and create the patch queue. >> <done> >> Though we are able to get the email and create the patch queue on the new >> aegis.apache.org machine, still we wont be able to trigger patch admin job >> on the hudson master as this is not allowed in the new setup. >> >> Infra team doesn't want us to run any builds on the hudson master. Instead >> they want all the builds to run on the slave machine. >> >> I got the password-less access for hudson user from hudson slave >> h1.grid.sp2.yahoo.net to aegis.apache.org like 2 weeks back. <done> >> >> The plan here is to read the patch queue on aegis from h1 and schedule >> builds. <I'm working on getting this to work> >> >> Longterm solution: >> email patch process and queue creation is un-reliable. As a long term >> solution we need to use jira-cli command line tool to read patch directly >> from jira. >> And doing this would require introducing a new workflow in jira. Apart from >> the current status called "patch-available" >> >> Thanks, >> Giri >> >> On Oct 20, 2010, at 12:54 PM, Konstantin Boudnik wrote: >> >>> Thanks for getting to it, Nigel. This is absolutely useful and allows to >>> keep >>> weeds out of the trunk up to a certain degree. >>> >>> There were at least two slightly different sources of information about >>> what's >>> going on with test-patch process. Would you mind to post a brief about the >>> situation so comments can be more substantial? >>> >>> Thanks, >>> Cos >>> >>> On Wed, Oct 20, 2010 at 12:47PM, Nigel Daley wrote: >>>> Folks, >>>> >>>> I'm working to get the pre-commit patch testing running again for HDFS, >>>> HADOOP, and MAPREDUCE patches. Since I've been on a bit of a hiatus from >>>> day-to-day involvement w/ the project over the last 6 months (new job), I >>>> want to check in and make sure folks would still find this pre-commit >>>> testing useful. Also, happy to hear any suggested improvement. Let me >>>> know. >>>> >>>> Cheers, >>>> Nige >> >
