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 was not proposing that promotion to full committership would be automatic.  I assume it would still be done via a vote by the PMC.  I agree that we cannot _guarantee_ committership for HCat committers in 6-9 months.  But I am trying to lay out a clear path they can follow.  If they don't follow the path then they won't be committers.  I am also trying to make it non-preferential in that I am setting the criteria to be what I believe the Hive PMC would expect any prospective Hive committer to do.  The only intended preferential part of the proposal is the Hive shepherds, which we have all agreed is a good idea.


On Dec 19, 2012, at 8:23 PM, Namit Jain 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
>>> committers
>>> as second class Hive citizens for the long run will not be healthy.  I
>>> propose the following as a starting point for discussion:
>>>> All active HCat committers (those who have contributed or committed a
>>> patch in the last 6 months) will be made committers in the HCat portion
>>> only of Hive.  In addition those committers will be assigned a
>>> particular
>>> shepherd who is a current Hive committer and who will be responsible for
>>> mentoring them towards full Hive committership.  As a part of this
>>> mentorship the HCat committer will review patches of other contributors,
>>> contribute patches to Hive (both inside and outside of HCatalog),
>>> respond
>>> to user issues on the mailing lists, etc.  It is intended that as a
>>> result
>>> of this mentorship program HCat committers can become full Hive
>>> committers
>>> in 6-9 months.  No new HCat only committers will be elected in Hive
>>> after
>>> this.  All Hive committers will automatically also have commit rights on
>>> HCatalog.
>>>> Alan.
>>>> On Dec 14, 2012, at 10:05 AM, Carl Steinbach wrote:
>>>>> On a functional level I don't think there is going to be much of a
>>>>> difference between the subproject option proposed by Travis and the
>>> other
>>>>> option where HCatalog becomes a TLP. In both cases HCatalog and Hive
>>> will
>>>>> have separate committers, separate code repositories, separate
>>> release
>>>>> cycles, and separate project roadmaps. Aside from ASF bureaucracy, I
>>> think
>>>>> the only major difference between the two options is that the