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 <st...@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.
