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

Reply via email to