(Sorry bout the duplicate msg Greg) Keeping the reference implementation in Hadoop proper seemed like the best idea when we would be tracking multiple versions of Hadoop. However, if those versions are Hadoop releases, then the same can probably be done easily with external code and Maven magic. The downside to hosting the Hadoop repository might be users who fork our clone and expect it to continually track upstream Hadoop. Sticking with point releases might be best? On Fri, Oct 26, 2012 at 4:00 PM, Gregory Farnum <greg@xxxxxxxxxxx> wrote: > If that's all we're interested in it seems like cloning their repo and > then checking out a specific version would be the right answer. ;) > I'm just a little concerned because we don't actually want to be > forking the Hadoop upstream and generally speaking a fork seems like > inviting accidental problems when all we want to do is look at a > single version of their upstream without actually importing it into > our tree. If there are other concerns I'm missing then they could > certainly be overriding, though! > > On Fri, Oct 26, 2012 at 3:47 PM, Joe Buck <jbbuck@xxxxxxxxx> wrote: >> Noah and I talked about this a bit and the idea was not to push our code upstream, but rather to host a fork locally so that we could decide when to rev the version(s) we build against rather than just pulling trunk from Hadoop's repo. We'd still be building the one or two .jar files that users would have to configure Hadoop to find, but we'd have a full version of Hadoop in our repo for consistency and what not. >> >> -Joe Buck >> >> On Oct 26, 2012, at 3:42 PM, Gregory Farnum wrote: >> >>> On Fri, Oct 26, 2012 at 3:29 PM, Noah Watkins <jayhawk@xxxxxxxxxxx> wrote: >>>> Development of the Hadoop shim layer is best done in the Apache Hadoop >>>> Git repository, so we can track up-stream and build for all the >>>> different versions that exist. Is keeping a clone in Inktank Github >>>> something that is possible / desired? >>> >>> Are we sure we want to maintain it in a fork of their repo? (I'm not >>> saying we don't, just curious.) QFS recently published support for >>> Hadoop and apparently they only need two JARs to support the things >>> that everybody is running now. Either way, see >>> http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201210.mbox/%3CCC946699.1C97B%25thilee@xxxxxxxxxxxxx%3E >>> and https://issues.apache.org/jira/browse/HADOOP-8885 for the >>> discussion surrounding (not) sending that upstream and the >>> distribution strategy they ended up with. >> -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
