hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Kay <kaykay.uni...@gmail.com>
Subject Re: Discussion: Move contribs out of hbase?
Date Fri, 29 Jan 2010 00:50:38 GMT
+1 on the idea , since that would be the natural migration path for 
contribs to step out separately.

As far as dependency management is concerned, we are pretty close except 
for zk / thrift . Once that is done - the dependent project should be 
good to maintain consistency with the hbase-core as well.

But it would be nice to maintain some sort of wiki  / documentation to 
consolidate the contribs in one place.  Also this can mean faster 
release cycles for contribs as well.



On 1/28/10 12:38 PM, Stack wrote:
> 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