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 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, instead
focusing only on their area of expertise, and familiarity with portions of
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 Hive
>is
>a problem. Hive itself became a subproject of Hadoop when it started with
>all the Hive committers becoming Hadoop committers. And of course everyone
>maintained the discipline that they commit in parts of the code that they
>understand and that they have worked on. Some of the committers from Hive
>ended up becoming Hadoop committers - others who worked only on Hive ended
>up leaving the Hadoop committers list once Hive became a TLP. So why put
>in
>these arguments about process when the end result would be beneficial to
>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 guidance
>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 if
>there are so many long term benefits from this then why focus on control
>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 and
>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 Hcat
>committers list on the Hive committers side (are there any?), then I think
>that should be addressed on a case by case basis but why enforce a general
>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 committers?
>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 before
>9 months are over? And if they don't get that expertise in 9 months would
>they really review and commit anything in the SemanticAnalyzer - I mean
>there are Hive committers who don't touch that piece of code today. no?
>
>Ashish
>
>
>On Wed, Dec 19, 2012 at 8:23 PM, Namit Jain <[EMAIL PROTECTED]> wrote:
>
>> I don’t agree with the proposal. It is impractical to have a Hcat
>>committer
>> with commit access to Hcat only portions of Hive. We cannot guarantee
>>that
>> a Hcat
>> committer will become a Hive committer in 6-9 months, that depends on
>>what
>> they do
>> in the next 6-9 months.
>>
>> The current Hcat committers should spend more time in reviewing patches,
>> work on non-Hcat areas in Hive, and then gradually become a hive
>> committer. They should not be given any preferential treatment, and the
>> process should be same as it would be for any other hive contributor
>> currently. Given that the expertise of the Hcat committers, they should
>> be inline for becoming a hive committer if they continue to work in
>>hive,
>> but that cannot be guaranteed. I agree that some Hive committers should
>>try
>> and help the existing Hcat patches, and again that is voluntary and
>> different
>> committers cannot be assigned to different parts of the code.
>>
>> Thanks,
>> -namit
>>
>>
>>
>>
>>
>>
>>
>> On 12/20/12 1:03 AM, "Carl Steinbach" <[EMAIL PROTECTED]> wrote:
>>
>> >Alan's proposal sounds like a good idea to me.