I am assuming that a contrib owner wants to see his code shipped as part of Hbase release and is willing to devote time and resources to make it happen. If he/she does not fix a build problem in time, then the release-build-process could ignore shipping that module as part of the hbase release.
For responsible owners of contrib modules this would be nice and acceptable; while contribs that have a non-responsive owner woudl automatically get filtered out from a hbase release, isn't it? On Thu, Jan 28, 2010 at 3:25 PM, Stack <st...@duboce.net> wrote: > On Thu, Jan 28, 2010 at 2:27 PM, Dhruba Borthakur <dhr...@gmail.com> > wrote: > > > Contribs are not first-class citizens. The build script can be setup to > > ignore build failures in contrib modules. The hope is that when a release > is > > about to be cut, contrib owners will submit fixes to any build problems > if > > they want their contrib to be shipped as part of the Hbase release. will > > this solve your problem? > > We could do that. > > I wouldn't be a fan though. Reconciling build issues in contribs is > still in the way of our making a release. When contribs are not > inline with the main build, there is no pressure on contrib owners to > address breakage in a timely fashion. Worst case, all fixes are left > till the last possible moment and a core committer has to do the > chasing to reconcile breakate. Broken builds, even if only under a > contrib would confuse interested users, methinks. > > Stepping back, IMO, contribs pollute and distract from the purity of > core and having the added functionality in subdirectories under hbase > core does contribs themselves a disservice in that they are not given > the chance to present themselves properly constrained as they are into > javadoc packaging. I see nothing wrong with users having to go to the > transactional hbase site, to take an example contrib, to get the > transaction hbase jar if they want to do transactions. Transactional > hbase can package itself as it wilt either as simple jar you drop into > an hbase install -- with plenty of elbow room for explanatory doc and > hype, or not as it chooses, up on the devoted transactional site -- > or as something more full-blown, a complete tarball that bundles core > with amended configuration. > > St.Ack > P.S. I heard a funny remark on hadoop contrib last night (I apologize > if apocryphal). Apparently, the easiest way to open source an internal > yahoo project was to somehow make it a subproject of hadoop. > -- Connect to me at http://www.facebook.com/dhruba
