Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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.
> >
> >+1
> >
> >On Dec 18, 2012 5:36 PM, "Travis Crawford" <[EMAIL PROTECTED]>
> >wrote:
> >
> >> Alan, I think your proposal sounds great.
> >>
> >> --travis
> >>
> >> On Tue, Dec 18, 2012 at 1:13 PM, Alan Gates <[EMAIL PROTECTED]>
> >>wrote:
> >> > Carl, speaking just for myself and not as a representative of the HCat
> >> PPMC at this point, I am coming to agree with you that HCat integrating
> >> with Hive fully makes more sense.
> >> >
> >> > However, this makes the committer question even thornier.  Travis and
> >> Namit, I think the shepherd proposal needs to lay out a clear and time
> >> bounded path to committership for HCat committers.  Having HCat
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB