[
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 output.
{quote}
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.
{quote}
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?
{quote}
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.
{quote}
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. :)
{quote}
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.
{quote}
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
(v6.3.4#6332)
