IMO, replication is a core feature.
I agree that contribs don't need the usual review and that owners if
committers should go ahead and commit.
St.Ack
On Thu, Feb 4, 2010 at 2:42 PM, Jean-Daniel Cryans <jdcry...@apache.org> wrote:
> 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
> core.
>
> J-D
>
> On Thu, Feb 4, 2010 at 1:57 PM, Jean-Daniel Cryans <jdcry...@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 <st...@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 <apurt...@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.br...@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
>>>
>>
>>
>
