incubator-bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: [VOTE] Bigtop 0.3.1: target release date, supported platforms, bill of materials
Date Fri, 07 Sep 2012 06:02:29 GMT
On Wed, Sep 05, 2012 at 05:50PM, Roman Shaposhnik wrote:
> On Tue, Sep 4, 2012 at 6:00 PM, Alan Gates <gates@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


Mime
View raw message