hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Discussion: Move contribs out of hbase?
Date Fri, 29 Jan 2010 06:35:13 GMT
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.unique@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.
> >>>>
> >>>>          
> >>>
> >>>
> >>>
> >>>
> >>>        
> >
> >
> >
> >
> >    



      


Mime
View raw message