Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Bigtop >> mail # dev >> [DISCUSS] Bigtop "singularity" branch/release

Copy link to this message
Re: [DISCUSS] Bigtop "singularity" branch/release

I might have a deja-vu, but I think we had this chat in the past: about making
odd/even releases with different stability scope (essentially similar to that
of Debian/Ubuntu model).

Anyway, I think it totally makes sense to have stable/stinging model moving
forward and I would be certainly very interested in helping with stable line's

There is a couple of concerns I want to discuss/clarify:
 # do we have enough bandwidth (like you've pointed earlier) for that
 # would we need a certain level of cross-branches cooperation especially in
   the area of deployment and the base framework (aka Bigtop) improvements? Is
   Bigtop itself is in a good enough shape where such cross-branches
   pollination would be limited and manageable? Or, perhaps, stable releases
   won't live for too long and this issue is totally immaterial?

Another way of addressing this multiple personality condition of Bigtop - as
Roman suggests in another email - is to do post-singularity work on a branch
without specific release dates/numbers in mind. Once there's a feeling that
such a post-singularity branch has ripened - we just release it, maybe with the
even/odd theme in mind.

So essentially there two options as I see it:
  - official acceptance for odd/even - or similar - release model with
    different stability scope
  - or going more agile - don't get me wrong, I don't like the word myself -
    and do all experimental development on a branch a release it on as needed

The latter in my opinion is a more sustainable approach going forward, because
it helps to bake new features on an experimental branch for a while and, if
needed, get selectively ported onto the current release branch. Which
accidently goes hand in hand with my favorite nvie.com/git-model

I believe the second choice above is essentially what you've proposed below
but expressed with Russian accent ;)


On Tue, Aug 06, 2013 at 10:37AM, Andrew Purtell wrote:
> If we do 0.7 as Stable as outlined below and then do a post-singularity 0.8
> as Unstable as outlined below, I volunteer to maintain that 0.7/Stable
> branch until the community decides to EOL it, i.e. 0.8 is the new Stable
> and 0.9 is ...
> On Tue, Aug 6, 2013 at 10:34 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
> > Do we have the bandwidth to do one stable distribution and another
> > unstable distribution, like Debian?
> >
> > We could be a bit aggressive with those terms, just given the nature of
> > the software here. For example:
> >
> > Stable - Hadoop 2.0.x, HBase 0.94, ZooKeeper 3.4.x, etc.
> >
> > Unstable - Hadoop 2.1.x, HBase 0.96, ZooKeeper 3.5 (if they release...).
> >
> > We would have two bleeding edges. One might sting a bit, but generally
> > addresses Cos' concerns (I think - Cos?). One might amputate a limb, but
> > would provide the whole ecosystem a peek at the post-singularity world.
> > There's already BIGTOP-1029.
> >
> >
> > On Mon, Aug 5, 2013 at 9:51 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
> >
> >> My main concern - as always - is a stability of the underlying components.
> >> And while the Bigtop's motto so far was 'the bleeding edge', that exactly
> >> what
> >> troubles me.
> >>
> >> I'd rather be a bit behind, but provide a stack with components that went
> >> through a certain degree of field testing. But it might be just me ;)
> >>
> >> Cos
> >>
> >> On Mon, Aug 05, 2013 at 09:38PM, Roman Shaposhnik wrote:
> >> > Hi!
> >> >
> >> > what I've noticed lately is that in quite a few
> >> > Hadoop ecosystem projects there have been
> >> > active work on 'singularity' releases. Two most
> >> > obvious example of this trend would be: Hadoop
> >> > 2.1.x-beta and HBase 0.96, but there's also
> >> > Hue 3.0, Oozie 4.0 and a few other things cooking.
> >> >
> >> > Perhaps it would make sense for us to stay ahead
> >> > of the game and offer an early opportunity for a
> >> > better integration to as many of these as we have
> >> > cycles/interest to tackle.