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.
On Feb 21, 2013, at 5:28 AM, Steve Loughran <[EMAIL PROTECTED]> 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.
> 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
> Has anyone asked the Maven team about options here?
> On 20 February 2013 16:46, Robert Evans <[EMAIL PROTECTED]> 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.