[
https://issues.apache.org/jira/browse/HADOOP-11929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568026#comment-14568026
]
Allen Wittenauer commented on HADOOP-11929:
-------------------------------------------
Given the statement
bq. . You don't need to "clue me in" that our unit test coverage (and test
coverage on Jenkins) is incomplete.
I'm sure you realize that test-patch.sh now re-executes itself when chunks of
dev-support has been patched. So it is an extremely common practice to include
other patches with test-patch patches to validate the test-patch changes
itself. So I'm sure you were just busy with other things when you wrote:
bq. I would like to see #5 split out into a separate patch so that it can be
more thoroughly reviewed. It seems like fairly straightforward test fixes.
But I'll go ahead and cancel/remove -04 so that it doesn't cause you any other
confusion.
bq. I would like to see a design document about this spelling out what the
goals are, how this patch achieves those goals, and what the plans are for the
future. It doesn't have to be long, but it does have to spell out what concepts
like "specializations" are, how the dependency management is supposed to work,
and what Hadoop developers will have to do to maintain this infrastructure in
the future.
Since there is no such thing as specializations in test-patch older, old, and
new, do I have to make something up? Or did you mean personalities which are
defined in the JIRA description or even the sample code in the hadoop.sh
prototype that's attached? Again, I'm sure you've just been way too busy to
read such details.
> 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-11929.04.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)
