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
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
PLEASE
On Fri, Apr 27, 2012 at 4:48 PM, Tom White t...@cloudera.com 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
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 t...@cloudera.com wrote:
Giri,
On Tue, Apr 17, 2012 at 8:36 PM, Giridharan Kesavan
gkesa...@hortonworks.com
On Tue, Apr 17, 2012 at 4:52 PM, Alejandro Abdelnur t...@cloudera.comwrote:
* 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
Giri,
On Tue, Apr 17, 2012 at 8:36 PM, Giridharan Kesavan
gkesa...@hortonworks.com wrote:
Alejandro,
On Tue, Apr 17, 2012 at 4:52 PM, Alejandro Abdelnur t...@cloudera.com wrote:
Giri,
I agree that running ALL tests all time takes a lot of time
(personally I'd prefer we do this at the
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 a...@cloudera.com wrote:
On Mon, Apr 16, 2012 at 2:14 PM, Alejandro Abdelnur t...@cloudera.comwrote:
* all
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
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
Alejandro,
On Tue, Apr 17, 2012 at 4:52 PM, Alejandro Abdelnur t...@cloudera.com 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
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
+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
+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,
On Mon, Apr 16, 2012 at 2:14 PM, Alejandro Abdelnur t...@cloudera.comwrote:
* 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
14 matches
Mail list logo
