PLEASE
On Fri, Apr 27, 2012 at 4:48 PM, Tom White wrote:
> Just to be clear, the HADOOP-8308 patch is selective about which tests
> it runs, so it doesn't increase build run times. Unless there are any
> objections, I'd like to commit the patch and switch Jenkins to run
> from the top-le
Just to be clear, the HADOOP-8308 patch is selective about which tests
it runs, so it doesn't increase build run times. Unless there are any
objections, I'd like to commit the patch and switch Jenkins to run
from the top-level directory early next week.
Cheers,
Tom
On Fri, Apr 27, 2012 at 2:21 AM
Dne 18.4.2012 0:17, Giridharan Kesavan napsal(a):
I agree with Aaron. Its going increase the test patch build timings
significantly which may not be very helpful
There are 9 build machines dedicated to hadoop. I would like that
automatic checking can finally test my patches like
MAPREDUCE-4116 <
I have a patch at https://issues.apache.org/jira/browse/HADOOP-8308
which takes the approach that Alejandro outlined.
Cheers,
Tom
On Wed, Apr 18, 2012 at 10:11 AM, Alejandro Abdelnur wrote:
> Giri,
>
> On Tue, Apr 17, 2012 at 8:36 PM, Giridharan Kesavan
> wrote:
>> Alejandro,
>>
>> On Tue, Apr
Giri,
On Tue, Apr 17, 2012 at 8:36 PM, Giridharan Kesavan
wrote:
> Alejandro,
>
> On Tue, Apr 17, 2012 at 4:52 PM, Alejandro Abdelnur wrote:
>> Giri,
>>
>> I agree that running ALL tests all time takes a lot of time
>> (personally I'd prefer we do this at the penalty of longer runs).
>>
>> Still
On Tue, Apr 17, 2012 at 4:52 PM, Alejandro Abdelnur wrote:
> * All patches must be at trunk/ level
> * All patches do a full clean TARBALL creation without running testcases
> * From the patch file we find out the maven modules and for those
> modules we do javac-warns/javadoc-warns/findbugs/testc
Alejandro,
On Tue, Apr 17, 2012 at 4:52 PM, Alejandro Abdelnur wrote:
> Giri,
>
> I agree that running ALL tests all time takes a lot of time
> (personally I'd prefer we do this at the penalty of longer runs).
>
> Still we have a problem to solve, we need to find a solution on
> test-patch workin
Giri,
I agree that running ALL tests all time takes a lot of time
(personally I'd prefer we do this at the penalty of longer runs).
Still we have a problem to solve, we need to find a solution on
test-patch working for ALL maven modules, currently changes outside of
common/hdfs/mapred or cross-pr
Giri,
I think Aaron was talking about not running all test cases for changes
to any project (e.g. HDFS and MapReduce). My proposal was to run all
the tests for any Common change. An HDFS change would only run HDFS
tests, and any MapReduce change would only run MapReduce tests.
Another thing I did
I agree with Aaron. Its going increase the test patch build timings
significantly which may not be very helpful
Im -1 on this.
-Giri
On Mon, Apr 16, 2012 at 2:22 PM, Aaron T. Myers wrote:
> On Mon, Apr 16, 2012 at 2:14 PM, Alejandro Abdelnur wrote:
>
>> * all testcases should always be run (
On Mon, Apr 16, 2012 at 2:14 PM, Alejandro Abdelnur wrote:
> * all testcases should always be run (else a change in hdfs could
> affect yarn/tools but not be detected, or one in yarn affect tools)
>
I'm -0 on this suggestion. Yes, it's a nice benefit to check all of the
dependent Hadoop sub-proje
+1,
I'd still go a bit further in the simplification of what testpatch does.
* patches must at root level (not even try to be smart)
* all testcases should always be run (else a change in hdfs could
affect yarn/tools but not be detected, or one in yarn affect tools)
Thxs.
Alejandro
On Mon, Apr
+1
This JIRA has been sitting patch available for a few weeks:
https://issues.apache.org/jira/browse/HADOOP-7416
I don't think it's quite ready for prime time (it doesn't implement all the
features you described) but it'd be a good starting point if someone wanted
to take it over the finish line.
Currently Jenkins QA builds don't support cross-project patches, since
they try to apply them to the hadoop-{common,hdfs,mapreduce}-project
tree, and reject any patches that are not strictly confined to that
tree. For changes that span projects (e.g. moving code from HDFS or MR
to Common, or build
14 matches
Mail list logo
