We could also have code coverage requirements for hbase contribs, or any other code metrics we might want to ensure that we aren't shipping utterly broken code.
I think the risk of being left out of a release packaging is the right kind of impetus to get someone to work on their contrib. It would also lower the barrier, and let us federate the source control (something ASF doesnt officially support). The latter is most important i think. I avoid SVN as much as possible :-) -ryan On Thu, Jan 28, 2010 at 3:42 PM, Dhruba Borthakur <dhr...@gmail.com> wrote: > 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 >
