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