Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hive >> mail # dev >> [DISCUSS] HCatalog becoming a subproject of Hive

Copy link to this message
Re: [DISCUSS] HCatalog becoming a subproject of Hive

I think Ashish is trying to avoid exactly this issue of any preferential
treatment to Hcat committers *becoming* Hive committers. If Hcatalog as a
subproject of Hive is accepted, both of us are advocating Hcat committers
becoming Hive committers immediately.

If you read Ashish's comment, it would become clear that when Hive, Pig
etc were subprojects of Hadoop, they had full Hadoop committership.

But none of them committed to hadoop core.

And that worked well.

So, why change the rules now ?

- Milind

Milind Bhandarkar
Chief Scientist,
Machine Learning Platforms,
Greenplum, A Division of EMC
+1-650-523-3858 (W)
+1-408-666-8483 (C)

On 12/20/12 1:59 PM, "Carl Steinbach" <[EMAIL PROTECTED]> wrote:

>I agree with Namit on this issue. I don't think it's fair to the
>existing group of Hive contributors to give preferential
>treatment to HCat committers, or to automatically promote them to
>full committer status on the Hive project.
>On Thu, Dec 20, 2012 at 1:10 PM, Bhandarkar, Milind <
>> I agree with Ashish.
>> When Hcat becomes a subproject of Hive, all Hcat committers should
>> immediately become Hive committers.
>> After all, that worked well for Hadoop, where all Hadoop committers can
>> commit to all Hadoop code (common/HDFS/MapReduce), but not all do,
>> focusing only on their area of expertise, and familiarity with portions
>> codebase.
>> - milind
>> ---
>> Milind Bhandarkar
>> Chief Scientist,
>> Machine Learning Platforms,
>> Greenplum, A Division of EMC
>> +1-650-523-3858 (W)
>> +1-408-666-8483 (C)
>> On 12/20/12 5:58 AM, "Ashish Thusoo" <[EMAIL PROTECTED]> wrote:
>> >Actually I don't understand why getting Hcat folks as committers on
>> >is
>> >a problem. Hive itself became a subproject of Hadoop when it started
>> >all the Hive committers becoming Hadoop committers. And of course
>> >maintained the discipline that they commit in parts of the code that
>> >understand and that they have worked on. Some of the committers from
>> >ended up becoming Hadoop committers - others who worked only on Hive
>> >up leaving the Hadoop committers list once Hive became a TLP. So why
>> >in
>> >these arguments about process when the end result would be beneficial
>> >the community and to the project. Would Hive not benefit if some folks
>> >from
>> >Hcat start working on Hive proper as well - of course under the
>> >of
>> >Hive mentors etc. Would the project not benefit in the long run if
>>Hcat is
>> >brought in and some day becomes the default metastore for Hive. I mean
>> >there are so many long term benefits from this then why focus on
>> >and code safety which I think any responsible committer knows how to
>> >navigate and there are well understood best practices for that. And why
>> >can't a committer be booted out if he/she is breaking the discipline
>> >really nosing in places which he/she does not understand.
>> >
>> >I mean if we agree that directionally Hcat being a part of Hive makes
>> >sense
>> >then why don't we try to get rid of the procedural elements that would
>> >only
>> >slow down that transition? If there is angst about specific people on
>> >committers list on the Hive committers side (are there any?), then I
>> >that should be addressed on a case by case basis but why enforce a
>> >rule. In the same vein why have a rule saying in 6-9 months a Hcat
>> >committer becomes a Hive committer - how is that helpful? If they are
>> >changing the Hcat subproject in Hive are they not already Hive
>> >And if they gain the expertise to review and commit code in the
>> >SemanticAnalyzer in a few months should they not be able to do that
>> >9 months are over? And if they don't get that expertise in 9 months
>> >they really review and commit anything in the SemanticAnalyzer - I mean