Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of kaykay.unique@gmail.com
 designates 209.85.210.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=FJpiXXart1xfS+KrHOxrdIjRF6ZvDb9rSxU2x7lmE6/BR7kPvIAg73d3Gr/aMAjK6K
         3vQaHy5AQRoBD3YdwYIWY5e1lQ6aFX72p4gs8l77nr7Cw1NYupnHZxDgIhNbgwr1rOkg
         ofwy0pd8Xf+aSOMBCsksKsKq92AfTTfQa3jZ4=
Message-ID: <4B62362A.3000207@gmail.com>
Date: Thu, 28 Jan 2010 17:13:14 -0800
From: Kay Kay <kaykay.unique@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: hbase-dev@hadoop.apache.org
Subject: Re: Discussion: Move contribs out of hbase?
References: <7c962aed1001281238g2c49d660pf47d23fe90432886@mail.gmail.com>
 <217106.58625.qm@web65509.mail.ac4.yahoo.com>
In-Reply-To: <217106.58625.qm@web65509.mail.ac4.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

As far as stargate  , providing rest api ,  I am tilted towards making 
it a first-class citizen as a contrib instead of having it in core ,  as 
I do not see that a primary feature being used although a very 
important, useful feature.

Once in google code , it is easy to integrate with their mvn repository 
as well.


On 1/28/10 4:09 PM, Andrew Purtell wrote:
> Putting Stargate into core is no big deal. This just undoes the migration
> of REST out into contrib. It's just a matter of moving around some files
> and adding a couple of targets to the toplevel build.xml.
>
> What do you want to do about the EC2 scripts? They make no sense as a
> standalone project in my opinion. Could move into bin/ec2/ ? What happens
> with those when they generalize to other cloud providers like the Hadoop
> cloud scripts are doing for 0.21? bin/cloud/ ? That would be fine with me.
>
>     - Andy
>
>
>
> ----- Original Message ----
>    
>> From: Stack<stack@duboce.net>
>> To: HBase Dev List<hbase-dev@hadoop.apache.org>
>> Sent: Fri, January 29, 2010 4:38:38 AM
>> Subject: Discussion: Move contribs out of hbase?
>>
>> I'd like to start a discussion on moving src/contrib out of hbase.
>> Keep reading if you have an opinion.
>>
>> I'd like to suggest that we undo the notion of hbase contribs for the
>> following reasons:
>>
>> + In my experience, they present a friction on changes to core as any
>> significant core change tends to ripple down into the contribs whether
>> its code or infrastructure/build changes.  Usually what happens then
>> is a non-expert in the contrib code is making edits -- often radical
>> -- to code they are not completely up on and are a little frustrated
>> that they have to do it.  Bad.
>> + A few of our contribs are maintained by non-committers.  This means
>> it takes a committers time getting in updates.  The owner is at mercy
>> of the committer making wanted changes.  The committer is consumed
>> reviewing and making update.  This indirection hurts at both ends (We
>> could discuss making contrib owners committers on their contrib only
>> but that'd be a bit of bureaucratic nightmare and a burden on the
>> hadoop pmc to vote on granting access to a subprojects, contrib.  Its
>> tough enough getting hadoop pmc to vote on hbase committers.  There is
>> no precedent in other project, to my knowledge).
>> + Contribs and core evolve at different rates.  They should not be
>> constrained by core release schedule (or the opposite, core should not
>> be held up because fixes in contrib are wanting).
>>
>> I suggest that current contribs be moved out of hbase up to standalone
>> github or google code projects (witness how hbql does it).  Previous
>> to our move to Ivy (and possibly soon, Maven), asking contribs be
>> standalone was a pain as they'd have to check in hbase jars and all of
>> dependencies and then move these forward over time.  Now that we are
>> Ivy-ized, contribs just need write a bit of ivy.xml and it'll take
>> care of pulling dependencies.
>>
>> I'd imagine support for contribs would go on as it does now with
>> queries up on hbase mailing list and help out on IRC.  We'd give
>> contribs first-class billing up on home page.  Popular contribs might
>> run their own mailing lists, etc...
>>
>> We should chat but some contribs should be pulled up into core.
>> Thrift was core.  Talk was to move current thrift update out to
>> contrib.  I think now it should just stay in core.  Stargate perhaps
>> should come up into core?
>>
>> What do folks think?
>> St.Ack
>>
>> P.S. I've fostered the contrib notion in the past.  I've since had a
>> change of heart.  Please pardon my flip.
>>      
>
>
>
>
>