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
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
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.
> 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