What have we decided here? Fold libhdfs3 back into HAWQ for the near term
and revisit spinning it out in a dedicated submodule / repo down the road?
Do we need to have a consensus vote for this action?

As for the outstanding PRs and issues in the current repo, who will be
moving those to HAWQ? Are we expecting users to do this? I'm taking the
"liberty" of responding to each of these users explaining the situation but
would like to know what to report on that front.


-Kyle

On Tue, Sep 20, 2016 at 3:30 PM Matthew Rocklin <mrock...@continuum.io>
wrote:

> Hi everyone,
>
> I plan to remove myself from the HAWQ mailing list (it's fairly high volume
> for non-developers).
>
> If further conversation on this issue occurs could I ask for someone to
> update one of the public issues?  Either something on Github or
> https://issues.apache.org/jira/browse/HAWQ-1046 ?
>
> -matt
>
> On Fri, Sep 16, 2016 at 7:14 AM, Matthew Rocklin <mrock...@continuum.io>
> wrote:
>
> > > Positively ignore the frustration of libhdfs3 users and about to delete
> >> it’s repository.
> >>
> >> I don't think the frustration is related to whether we delete it or not,
> >> I think
> >> the frustration is related to the fact the current model of libhdfs3
> >> living in a
> >> random, separate GH repo:
> >>    1. does NOT have a clear governance model: the bigger ASF community
> >> doesn't
> >>    really monitor pull request, there's not clear way of filing issues
> >> against it, etc.
> >>
> >>    2. does NOT have a clear release policy: last release appears to be
> >> Dec 17, 2015
> >>    and even that doesn't clearly indicate what was the release criteria
> >> for it.
> >>
> >>    3. does NOT have a clear path of integration with HAWQ.
> >>
> >
> > Speaking just for myself here actually I care much less about the points
> > above than you might think.  I don't need libhdfs3 to be governed by the
> > ASF to find it useful.  I don't mind packaging up and using unreleased
> > versions.  I don't care that it isn't integrated with HAWQ (in fact, I
> > somewhat prefer that it remains separate).  I *do *prefer that it lives
> > in a separate repository on GitHub.
> >
> > I don't mean to be contrarian here, just clarifying where I can clarify.
> > My situation/priorities may not be representative.
> >
>
-- 
*Kyle Dunn | Data Engineering | Pivotal*
Direct: 303.905.3171 <3039053171> | Email: kd...@pivotal.io

Reply via email to