[
https://issues.apache.org/jira/browse/BIGTOP-718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13465749#comment-13465749
]
Arun Singla commented on BIGTOP-718:
------------------------------------
bq. I would like to add that this set of goals have served us well through the
incubation and graduation processes.
That is precisely the reason why the goals should be crisply added to the
project homepage and documentation. So far, there were only a few people
contributing to the project and now there would be many more. The goals were
clear to these early contributors but it would start causing confusion moving
forward.
bq. Our project has to have a clear set of bylaws defining, among other things,
set of voting rules, and so on and so far. So, let's deal with that first and
foremost.
+1 on the need to have clarity on the bylaws. But that doesn't seem to suggest
that we shouldn't improve wiki navigation and fix general documentation.
bq. 1. A component be part of the Apache Hadoop ecosystem (per your comment
about "Big Data" we need to define that better but I'd start with integrates
with and/or is powered by Apache Hadoop).
+1
bq. 2. A requirement that all components are added to trunk before release
branches. We articulate something similar in Hadoop (see
http://wiki.apache.org/hadoop/Roadmap), in general it's good to be trunk first
so different Bigtop releases don't have inconsistent components
+1, The community already has several commercially supported Hadoop distros -
that are meant to be stable and have inconsistent set of components for their
respective corporate reasons. These are already causing plenty of confusion in
a user's mind. Bigtop distro doesn't necessarily need to be a production ready
distro and doesn't need to have inconsistent branches. Bigtop is first and
foremost serving the purpose of being a bleeding edge collection of hadoop
components, and so it needs to grow up in one direction. With that thought a
Trunk First Model sounds fundamental to Bigtop, IMO.
bq. 3. A requirement that new components work with all of the existing
components before they are included in a release. New additions can bake in
trunk or a feature branch but we shouldn't release them until they work with
the rest of the stack (for the other parts of the stack they interact with).
bq. 4. I'd clarify that the projects dependencies need to be ASFv2 compatible
(which is implied but better to be clear)
+1, It is better to be clear and even more so now
bq. 5. I'd consider making integration testing a hard requirement
+1, Without integration testing it would be become a mess
> Update wiki for component requirements
> --------------------------------------
>
> Key: BIGTOP-718
> URL: https://issues.apache.org/jira/browse/BIGTOP-718
> Project: Bigtop
> Issue Type: Improvement
> Components: Documentation
> Reporter: Sean Mackrory
> Assignee: Sean Mackrory
>
> I think some updates are in order for this Wiki page in order to more
> accurately reflect the goals of the project:
> https://cwiki.apache.org/confluence/display/BIGTOP/Requirement+for+adding+a+new+component+to+Bigtop+distribution.
> For starters, it should have a more prominent link on the Wiki and a summary
> on the project home page. Not only is it going to be an increasingly common
> question, but it's an important part of defining what "Bigtop" is really all
> about. I know when I first started on the project it was the first thing I
> looked for.
> Second, we say projects have to be "Big Data"-related. Judging by other
> documents* and existing discussions regarding new components, it seems like
> we really mean to say "Hadoop"-related, and I think the extra focus would be
> good (having said that, I do think of Spark as Hadoop-related).
> * https://cwiki.apache.org/confluence/display/BIGTOP/Index
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
