Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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

Hi Andy,

my remark about the deja-vu wasn't intent to hurt, just you know.... a remark ;)

I think we are converging here and I can buy into your proposal about three
lines of the development if needed. So, process wise, I don't see any
problems here.

On the technical side, I'd seriously would urge people to review the branching
model from my earlier reference (nvie.com/git-model) as it would fit our
situation beautifully and will ease the pain of bringing feature cross
multiple branches.

Cos

On Wed, Aug 07, 2013 at 10:24AM, Andrew Purtell wrote:
> Replies inline, prefixed with [Andrew]
>
>
> On Tue, Aug 6, 2013 at 9:39 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:
>
> > Andrew,
> >
> > 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).
> >
>
> [Andrew] Maybe I was around for this discussion before. Apologies. Some
> days by dinner time I forget what I had for lunch.
>
>
> > 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
> > maintenance.
> >
> > 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?
> >
>
> [Andrew] The lifetime of a stable release could depend on the available
> project bandwidth and the observed rate of new releases off the components'
> release branches. Or it could be an emergent decision process - if release
> branches have a maintainer (a committer), then the branch would live as
> long as the maintainer still has an interest in that branch, or if someone
> else steps up should the current maintainer move on, or else EOL. I like
> the latter. PMC can step in if there is neglect.
>
>
> > 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
> >     basis.
> >
> > 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 ;)
> >
>
> [Andrew] For me the stable/unstable even/odd scheme is just an artifact
> considering POMs must be versioned and users will be familiar with this
> model from elsewhere.
>
> In terms of the nvie model, given the upstream singularities, might there
> be for a time a three way branching? E.g.
>
>      stable
>
>      unstable
>
>      development
>
> The "stable" and "unstable" branches would be release branches, coinciding
> with a Hadoop ecosystem based on 2.0.x and successor, respectively. We can
> give one an even number and the other an odd one to reflect our estimate of
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB