incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <>
Subject Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms, bill of materials
Date Fri, 07 Sep 2012 06:18:59 GMT
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 <> 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
> >> If you say you will only take new projects on your trunk, but your trunk is
> >> 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.


View raw message