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 <[email protected]> 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
<[email protected]> 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
