I prefer git over svn also. I hope the ASF includes support for it in the dev infrastructure some day. When first working on Stargate, Brian Beggs and I had it up on github. I remember disliking having two totally separate sets of workflow tools. It was more work for me. Call me lazy, or a curmudgeon, but I have enough things to do already.
- Andy ----- Original Message ---- > From: Ryan Rawson <ryano...@gmail.com> > To: hbase-dev@hadoop.apache.org > Sent: Fri, January 29, 2010 7:54:34 AM > Subject: Re: Discussion: Move contribs out of hbase? > > 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 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 wrote: > > > >> On Thu, Jan 28, 2010 at 2:27 PM, Dhruba Borthakur > >> 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 > >
