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
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
the maturity of the upstream sources. The development branch would be where
changes to Bigtop itself happen. Those changes would go back to the release
branches as desired, done by the release branch maintainer as they see fit.
Perhaps we would also publish Maven snapshots directly from the dev branch

Just some thoughts for your consideration.
> Regards,
>   Cos
> 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]>

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)