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 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, 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