I am more with Dhruba on this one. Let contrib stay there that are maintained (I assume a committer owns it) and those that are not maintained and fall behind will be dropped if they are not done by a certain deadline before a release. That will weed out the old contribs but keeps the project together with the important ones being maintained readily available.
On Fri, Jan 29, 2010 at 7:35 AM, Andrew Purtell <apurt...@apache.org> wrote: > Anyone can take the source out of the Apache SVN tree and import it. If you'd > like to do that, please go ahead. > > > Or we can move REST back into core if Thrift is going to stay there. > > - Andy > > > ----- Original Message ---- >> From: Kay Kay <kaykay.uni...@gmail.com> >> To: hbase-dev@hadoop.apache.org >> Sent: Fri, January 29, 2010 2:04:13 PM >> Subject: Re: Discussion: Move contribs out of hbase? >> >> 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 >> >> 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. >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> >> >>> >> > >> > >> > >> > >> > > > > > > >
