-0 on graduation into Hive.
>From the [DISCUSS] thread: http://s.apache.org/as9 , this sounds like
a compromise with members of the Hive PMC who see HCatalog as "a set
of wrapper APIs that make Hive's metastore and serdes accessible to
Pig and MR", so they question whether members of that community can
discharge the responsibilities of Hive committers (reviewing patches,
etc.). Others claim it's unfair to existing Hive contributors to
extend committership based on group membership rather than the
criteria they've applied to individuals. Is that a fair summary?
It's a delicate thing to merge communities, but if the Hive PMC is
unwilling to share authority with the HCatalog developers, then Hive
is voting to take a dependency on HCatalog in exchange for control
over its development. Those bylaws are a prenup, granting existing
Hive developers privilege over the assets of both parties. Maybe the
HCatalog community prefers this to its other options, but it's an odd
arrangement.
If the HCatalog code is core to Hive and a significant delta, then I
agree with ChrisM: merge the projects or don't. If the code a
community produces is good enough to adopt, then why subject members
of that community to this audit? Why endure the meddling from outside
the project over unorthodox bylaws? Is this an avoidable waste of
energy?
Which is not to say that Hive devs don't have good, even technical
reasons for adding these protections. Adding all those people will
make the project different, and different could be worse. But allowing
passion for the project's integrity to trump an honest accounting of
its membership invites a permanent discussion that will embitter
everyone. It's clear this is a carefully negotiated, trial merge of
the projects, so it's fair to assume all parties know what's in their
interest, but I hope the costs are fully appreciated as they move
forward. -C
On Mon, Feb 11, 2013 at 10:40 AM, Mattmann, Chris A (388J)
<chris.a.mattm...@jpl.nasa.gov> wrote:
> Hi Alan,
>
> On 2/11/13 10:20 AM, "Alan Gates" <ga...@hortonworks.com> wrote:
>
>>
>>On Feb 8, 2013, at 9:03 PM, Mattmann, Chris A (388J) wrote:
>>
>>> Hi Alan,
>>>
>>> Thanks for the pointer.
>>>
>>> I'm -1 on this graduation for the following reasons:
>>>
>>> 1. It looks eerily similar to the creation of umbrella projects. I would
>>> expect the ASF board to not be happy with the graduation of a podling as
>>> effectively a sub project of an established TLP, with the sub project
>>> status maintained through a rather lengthy set of bylaws that after
>>>trying
>>> to read through for about 5 mins I decided to stop. TL;DR
>>
>>Our goal is not to repeat the umbrella project situation that happened
>>with Hadoop. The goal is to give the Hive community time to get to know
>>the HCatalog committers and time for the HCatalog community to learn
>>about Hive beyond the metadata portions they have been working with.
>
> IMO, the above statement conflicts with the below statement:
>
> {quote}
> Because we believe it makes sense, from both a community and code
> perspective, that these projects are together. HCatalog opens up Hive's
> metadata for use by other tools on Hadoop and for external systems. It
> doesn't make sense to any of us that this is separated from Hive with a
> different PMC, different release cycle, etc.
>
> {quote}
>
> If it makes sense from a community and code perspective to bring the
> projects together, there shouldn't be a need for time from the Hive
> community to get to know HCatalog (or vice versa). Either they know the
> code and/or are willing to take on its stewardship (which kind of
> necessitates knowing the code), or they don't.
>
>> To avoid the umbrella project status the by laws specifically prohibit
>>creating new committers with access only to HCatalog. Also, it has been
>>agreed that each HCatalog committer will be provided with a mentor from
>>the Hive community to help him/her learn the rest of Hive, with the goal
>>of becoming a committer on Hive within six months. The submodule state
>>is transitionary, not an end point.
>
> Why introduce a transitionary state then? If in 6 months Hive and HCatalog
> are ready to merge, you can just as easily create a board resolution to
> merge the 2 projects at the time, the Incubator -> TLP and TLP status is
> not an end state.
>
> However, I'm against setting a precedent for umbrella project creation,
> which I believe this to be.
>
>>
>>>
>>> 2. If the two communities can't be merged by simply merging the PPMC
>>>into
>>> the PMC, then why not simply graduate HCatalog as its own TLP?
>>
>>Because we believe it makes sense, from both a community and code
>>perspective, that these projects are together. HCatalog opens up Hive's
>>metadata for use by other tools on Hadoop and for external systems. It
>>doesn't make sense to any of us that this is separated from Hive with a
>>different PMC, different release cycle, etc.
>
> It's been separated while in Incubation, so nothing is changing if it
> becomes a TLP, it's business as usual. And if in 6 months, the Hive PMC is
> ready to accept the HCatalog PMC (and vice versa), then deal with it then
> as 2 TLPs becoming 1 TLP.
>
> But I'm not going to VOTE positively for a graduation that requires bylaws
> to draw these artificial lines which already exist at the ASF and have
> been around for quite a while longer than any of us have at the
> Foundation.
>
> Chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
