hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Daniel Cryans <jdcry...@apache.org>
Subject Re: Discussion: Move contribs out of hbase?
Date Thu, 04 Feb 2010 22:42:17 GMT
I'd like to add a rule for contrib, that it doesn't need +1 from others for
the owner to commit changes. I think it was already a non-verbal rule as
most of the ec2 and stargate stuff was committed directly after the issue
was opened and it's good because it gives more agility and it doesn't break


On Thu, Feb 4, 2010 at 1:57 PM, Jean-Daniel Cryans <jdcryans@apache.org>wrote:

> What about replication? I think it is a core feature but the reason we
> wanted to put it first in contrib was because of stability issues it could
> generate. 2 other options:
> - github, means no visibility from hbase and more steps to get it
> - directly into core, with a configuration variable that works the same way
> as dfs.append.enable
> J-D
> On Thu, Feb 4, 2010 at 1:50 PM, Stack <stack@duboce.net> wrote:
>> Trying to summarize the above back and forth, how about going forward
>> we do something like the following:
>> + We keep contrib
>> + Look into having build NOT go down to contrib dirs by default so
>> broken contrib doesn't hold up core
>> + Core devs no longer are required chase changes all the ways down
>> into each of the contrib tributaries; onus on rectifying contrib with
>> core changes falls on contrib owner.
>> + Allow that if a contrib is not fixed promptly, it will dropped from a
>> release
>> + Move those contribs we consider core -- stargate for example -- up
>> into core and out of contrib (thrift is a little more involved;
>> depends on how Lars Francke wants to run it)
>> + Raise the barrier when it comes to taking on new contribs; encourage
>> satellite projects to use other repos
>> To be clear, current contrib owners are: andrew for ec2 and stargate,
>> clint morgan for THBase ('transactional') and I'm covering IHBase
>> ('indexed').
>> If above is not objectionable, I'll stick it up on the wiki as a sort
>> of contrib 'policy'.
>> Here's some other comments on items raised over course of this discussion:
>> On Thu, Jan 28, 2010 at 4:09 PM, Andrew Purtell <apurtell@apache.org>
>> wrote:
>> > 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.
>> >
>> IMO bin/ec2 seems grand but maybe just wait till after 0.21 because
>> when the generalized scripts become available, it might dictate they
>> belong somewhere else -- a bin/cloud or somewhere else altogether.
>> On Sun, Jan 31, 2010 at 5:18 AM, Bruce Williams
>> <williams.bruce@gmail.com> wrote:
>> >
>> > Providing an interface for contrib to code to is the ultimate solution.
>> >
>> Interestingly, contribs have been instrumental here.  Much of hbase
>> core is subclassable and you can configure it to use alternate
>> implementations of Master, RegionServer, Region, etc.
>> Thanks,
>> St.Ack

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message