[ https://issues.apache.org/jira/browse/HAWQ-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15502823#comment-15502823 ]
Bolke de Bruin edited comment on HAWQ-1046 at 9/19/16 9:21 AM: --------------------------------------------------------------- Here a (potential) user of libhdfs3. I have read through the mailing list thread and I don't find myself fully represented as a stakeholder of libhdfs3. Some assumptions have been made about problems in governance, driving force and community that in my opinion are not entirely correct. I think that the current structure and entanglement with HAWQ is hampering community growth around libhdfs3. PRs and issues are not being addressed. A somewhat maintained version of libhdfs3 in present in HAWQ, but it only has one stakeholder and that is HAWQ itself. Finding, pulling and building the HAWQ maintained version out of the HAWQ repositories is a major PITA. This does not encourage its use outside of HAWQ. Secondly, I think an independent maintained libhdfs3 with its own governance and no unrelated dependencies (eg. HAWQ), will benefit the larger ecosystem and benefit HAWQ at the same time as improvements will be made by a larger community that is centered around libhdfs3. Driving forces can come (and do come already) from the Python 3 community (there is no ready alternative in this space!), Hadoop and Hadoop Security community and obviously HAWQ. Finally, I don't think there will be a governance issue within HAWQ itself. Many apache projects rely (in core) on projects outside AFS' governance. If you are afraid of what happens to a "random github repository" you rely on the license and make sure to have a downstream copy. This is what you are doing now more or less. Ideally you generate a place for the libhdfs3 community to organize itself. This could be ASF be it could also be some random github page. I think I am arguing to trust the community instead of trying to (over?) govern. was (Author: bolke): Here a (potential) user of libhdfs3. I have read through the mailing list thread and I don't find myself fully represented as a stakeholder of libhdfs3. Some assumptions have been made about problems in governance, driving force and community that in my opinion are not entirely correct. I think that the current structure and entanglement with HAWQ is hampering community growth around libhdfs3. PRs and issues are not being addressed. A somewhat maintained version of libhdfs3 in present in HAWQ, but it only has one stakeholder and that is HAWQ itself. Finding, pulling and building the HAWQ maintained version out of the HAWQ repositories is a major PITA. This does not encourage its use outside of HAWQ. I think an independent maintained libhdfs3 with its own governance and no unrelated dependencies (eg. HAWQ), will benefit the larger ecosystem and benefit HAWQ at the same time as improvements will be made by a larger community that is centered around libhdfs3. Driving forces can come (and do come already) from the Python 3 community (there is no ready alternative in this space!), Hadoop and Hadoop Security community and obviously HAWQ. I don't think there will be a governance issue within HAWQ itself. Many apache projects rely (in core) on projects outside AFS' governance. If you are afraid of what happens to a "random github repository" you rely on the license and make sure to have a downstream copy. This is what you are doing now more or less. Ideally you generate a place for the libhdfs3 community to organize itself. This could be ASF be it could also be some random github page. I think I am arguing to trust the community instead of trying to (over?) govern. > Document migration of LibHDFS3 library to HAWQ > ---------------------------------------------- > > Key: HAWQ-1046 > URL: https://issues.apache.org/jira/browse/HAWQ-1046 > Project: Apache HAWQ > Issue Type: Wish > Components: libhdfs > Reporter: Matthew Rocklin > Assignee: hongwu > Fix For: backlog > > > Some people used to depend on the libhdfs3 library maintained alongside HAWQ. > This library was merged into the HAWQ codebase, making the situation a bit > more confusing. > Is independent use of libhdfs3 still supported by this community? If so what > is the best way for packagers to reason about versions and releases of this > component? It would be convenient to see documentation on how people can > best depend on libhdfs3 separately from HAWQ if this is an intention. > It looks like people have actually submitted work to the old version > See: https://github.com/Pivotal-Data-Attic/pivotalrd-libhdfs3/pull/28 > It looks like the warning that the library had moved has been removed: > https://github.com/Pivotal-Data-Attic/pivotalrd-libhdfs3/commit/ddcb2404a5a67e0f39fe49ed20591545c48ff426 > This removal may lead to some frustration -- This message was sent by Atlassian JIRA (v6.3.4#6332)