On Thu, Sep 06, 2012 at 08:09AM, Alan Gates wrote: > > 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.
I think the optics in question is how stable a release line looks to the outside world. Adding experimental or unstable components might not be favorably perceived by the potential consumers of the artifacts. However, I see the danger of a potential isolation if nothing new but updates are added up to a stack. So, perhaps a balanced approach like one Roman has mentioned earlier is a very good way forward. Cos
signature.asc
Description: Digital signature
