On Sep 5, 2012, at 5:50 PM, Roman Shaposhnik wrote: > On Tue, Sep 4, 2012 at 6:00 PM, Alan Gates <ga...@hortonworks.com> wrote: >> Doing this leaves new projects wedged. Not many people are on Hadoop 2.0 >> yet. >> Thus a lot of projects (including new ones like Ambari) are focussed on >> Hadoop 1.0. >> If you say you will only take new projects on your trunk, but your trunk is >> focussed >> on code most people haven't migrated to yet it seems you're limiting both >> Bigtop and new projects. > > Two comments: > * it would be very nice if Hadoop offered MapReduce independently > of HDFS. At this > point I'd say that users are way better off with HDFS coming > from Hadoop 2.0 codeline, > while the jury is still out on YARN wrt. operational stability > as compared to Hadoop 1.0. > Thus, if only we had an option of mixing and matching the 2 -- > that would have offered > the best of both worlds. All that's being hashed out in the Hadoop community at the moment, though the momentum seems to be with staying together for now. Even if they split the project tomorrow there are still a lot of people using Hadoop 1.x (and 20.x, and ...) who will be in no hurry to upgrade, thus there will be projects wanting to target that line for a while.
> * I agree with Cos/Bruno that perhaps it is not worth upsetting > Bigtop 0.3.0 line, if only > because of optics and perception. Perhaps the right question to > ask (on a different > thread) is whether Bigtop needs to accommodate a sort of > even/odd release mentality of a > Linux kernel. I'm not sure what optics you're worried about here. Just add new projects and mark them as alpha or experimental or whatever until they've gone through a few releases. But whatever. If we believe it's better to have a Bigtop 5.x that is Hadoop 1.x plus newer projects that seems fine. We just need some way to push out newer projects that are based on older Hadoop. Alan. > > Thanks, > Roman.
