[
https://issues.apache.org/jira/browse/HADOOP-11929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14565529#comment-14565529
]
Allen Wittenauer commented on HADOOP-11929:
-------------------------------------------
bq. I could be misinterpreting here, but it sounds like you are advocating
doing less testing in the precommit build and relying more on the nightly and
weekly builds.
Not only 'here', but pretty much the entire purpose of this JIRA.
I'm advocating *realistic* testing in precommit. Doing everything, all the
time isn't realistic with a project of this size and complexity while still
serving the community in an efficient manner. There is a happy medium.
bq. If we should be doing anything, it is increasing the amount of precommit
testing.
.. and ultimately, this patch will do that. It will turn on a lot of the
things that are currently off and be a key enabler for other things in the
future.
bq. We could get into a situation where a piece of code wasn't being tested for
months or even years (it's happened in the past...)
Given your comments thus far, let me clue you in: it's happening now, even in
the nightly build, because we don't have everything turned on and/or it's
inappropriate for test-patch to do it and/or it's currently impossible to do so
(e.g., missing dependencies, missing JVMs, etc).
bq. The whole premise of this change is that we should spend more human time
building and maintaining a complex explicit dependency management
infrastructure to save CPU time on the build cluster.
This is when I throw my hands up. It's very obvious at this point you have
zero understanding of the issues and the purpose of this JIRA.
> add test-patch plugin points for customizing build layout
> ---------------------------------------------------------
>
> Key: HADOOP-11929
> URL: https://issues.apache.org/jira/browse/HADOOP-11929
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Sean Busbey
> Assignee: Allen Wittenauer
> Priority: Minor
> Attachments: HADOOP-11929.00.patch, HADOOP-11929.01.patch,
> HADOOP-11929.02.patch, HADOOP-11929.03.patch, hadoop.sh
>
>
> Sean Busbey and I had a chat about this at the Bug Bash. Here's the proposal:
> * Introduce the concept of a 'personality module'.
> * There can be only one personality.
> * Personalities provide a single function that takes as input the name of
> the test current being processed
> * This function uses two other built-in functions to define two queues:
> maven module name and profiles to use against those maven module names
> * If something needs to be compiled prior to this test (but not actually
> tested), the personality will be responsible for doing that compilation
> In hadoop, the classic example is hadoop-hdfs needs common compiled with the
> native bits. So prior to the javac tests, the personality would check
> CHANGED_MODULES, see hadoop-hdfs, and compile common w/ -Pnative prior to
> letting test-patch.sh do the work in hadoop-hdfs. Another example is our lack
> of test coverage of various native bits. Since these require profiles to be
> defined prior to compilation, the personality could see that something
> touches native code, set the appropriate profile, and let test-patch.sh be on
> its way.
> One way to think of it is some higher order logic on top of the automated
> 'figure out what modules and what tests to run' functions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
