+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 16, 2012 at 1:55 PM, Aaron T. Myers <a...@cloudera.com> wrote: > +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. > > -- > Aaron T. Myers > Software Engineer, Cloudera > > > > On Mon, Apr 16, 2012 at 1:51 PM, Tom White <t...@cloudera.com> wrote: > >> 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 system changes) developers have to run test-patch >> and tests manually, which is cumbersome. >> >> I'd like to propose that we change the Common Jenkins build so that it >> runs from the top-level >> (http://svn.apache.org/repos/asf/hadoop/common/trunk). The HDFS and >> MapReduce builds would be unchanged. This would have two implications: >> i) all patches would have to be rooted at the top-level, and ii) the >> unit tests for all projects would be run for Common changes. >> >> I think i) is reasonable (and most patches are like this now) - and >> it's easy to regenerate a patch that is rooted at the wrong level. For >> ii), running all tests for a change in Common is probably a good thing >> to do in general. >> >> Thoughts? >> >> Tom >> -- Alejandro
