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.
