On Wed, Sep 05, 2012 at 05:50PM, 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. > * 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 actually like the idea about even/releases. On one hand it gives us a way of keeping a stable releases line (updates only); and having a line where new components (in alpha version or whatever) can be added for those who are willing to experiment. In the hind side, locking the line forever doesn't look like viable approach in the long run. Cos
signature.asc
Description: Digital signature
