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

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.

Alan.

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