hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-12361) reorganize repo layout for break from Hadoop code base
Date Fri, 04 Sep 2015 14:27:47 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-12361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14730878#comment-14730878

Sean Busbey commented on HADOOP-12361:

bq. Any thoughts on where/how to handle unit tests? As soon as the layout gets settled, I
want to start getting some in...

presuming you mean for test-patch, I profess ignorance at testing bash scripts and am willing
to accept near anything. I think using make to drive running whatever we use makes sense from
a portability perspective, and I think it would benefit us to standardize on using TAP for

bq. any particular reason? in the case of version-info I think I've convinced myself that
it should go to the Maven project. But we'll like have some other java artifact at some time
in the future. I've been presuming the different components will be versioned independently,
since they aren't directly tied to each other.

>From what I've seen of the build systems we support, maven is probably the best for support
Java-based bits.

For the Java-based implementations I agree, I'm just not sure why that would mean we need
to use Maven to provide a unified build across the components we create. For example, I'd
be surprised if we end up with more than a hand-full of version changes for the audience annotations
artifact just because it seems very stable. Why would someone currently working on e.g. release-doc-maker
care how the artifacts for the audience annotations  are made?

bq. I've been hoping (and the current proposal presumes) that we'll use the new git based
publishing system (ref blog), which I think will render markdown (or asciidoc or whatever)
for us.

We should verify that.

Good idea. I'll take a look at whomever is currently using it and see what I can find. the
docs are... a place where we can provide value back to the wider asf community. :)

bq. we you thinking a common docs/ dir would be easier to migrate to whatever gets decided?
I think per-"project" docs are the way to go, but just worried about having five files called
README.md and what that means for web site generation.

It's my understanding that the git-hosted-website works like Github pages, where the website
source lives in a different branch than the main code base. That would leave us free to use
README.md for guidance in the source itself while building a coherent presentation for teh
web site elsewhere.

> reorganize repo layout for break from Hadoop code base
> ------------------------------------------------------
>                 Key: HADOOP-12361
>                 URL: https://issues.apache.org/jira/browse/HADOOP-12361
>             Project: Hadoop Common
>          Issue Type: Sub-task
>          Components: yetus
>    Affects Versions: HADOOP-12111
>            Reporter: Sean Busbey
>            Assignee: Sean Busbey
>         Attachments: HADOOP-12361.HADOOP-12111.1.sh
> Reorganize current top level repo to include our starting modules (and only those modules),
so that it's easier to start bringing in new contributors:
> * shelldoc
> * releasedocmaker
> * interface audience
> * test-patch

This message was sent by Atlassian JIRA

View raw message