You can register the initial version under your own name and I will be
able to support it for sometime in the immediate future , as I have a
vested interest in it , being one of the users of it in the current
form. Let me know your thoughts on the same.
On 01/28/2010 07:41 PM, Andrew Purtell wrote:
That's fine but I don't want to maintain my own project in google code. So maybe
someone else can take over?
----- Original Message ----
From: Kay Kay<kaykay.uni...@gmail.com>
To: hbase-dev@hadoop.apache.org
Sent: Fri, January 29, 2010 9:13:14 AM
Subject: Re: Discussion: Move contribs out of hbase?
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
To: HBase Dev List
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.
