Just wanted to give everyone a heads up. Due to this change, I have introduced a bug.
It's returning opposite value of what it's supposed to. So, +1 of all tests you change brings up a -1 overall and vice versa. I have reopened HADOOP-9112 and uploaded the patch to reverse to reverse to the correct return values. Once a committer goes ahead with, it will be corrected. Sorry about the inconvenience. Thanks, Surenkumar Nihalani. On Feb 21, 2013, at 5:28 AM, Steve Loughran <ste...@hortonworks.com> wrote: > thanks, just seen and commented on this. > > IF we're going to have test timeouts, we need a good recommended default > value for all tests except the extra slow ones. > > Or > 1. we just use our own JUnit fork that sets up a better default value than > 0. I don't know how Ken would react to that. > 2. we get maven sure to support a programmable (default) timeout for every > test case. This is probably easier, and would work for all existing tests > too. > > Has anyone asked the Maven team about options here? > > On 20 February 2013 16:46, Robert Evans <ev...@yahoo-inc.com> wrote: > >> Sorry about cross posting, but this will impact all developers and I >> wanted to give you all a heads-up. >> >> HADOOP-9112<https://issues.apache.org/jira/browse/HADOOP-9112> was just >> checked it. This means that the pre commit build will now give a –1 for >> any patch with junit tests that do not include a timeout option. See >> http://junit.sourceforge.net/javadoc/org/junit/Test.html for more info on >> that. This is to avoid surefire timing out junit when it gets stuck and >> not giving any real feedback on which test failed. >> >> --Bobby >>
