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 > 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 > periodically. > > 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]> > > 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. > > > >> > > > > >> > I'd appreciate your thoughts and feedback on how > > > >> > useful/feasible this might be. > > > >> > > > > >> > Thanks, > > > >> > Roman. > > > >> > > > > >> > P.S. Two clear example of Bigtop JIRAs which are > > > >> > prime candidate for a 'singularity' branch/release > > > >> > of Bigtop are, of course: > > > >> > https://issues.apache.org/jira/browse/BIGTOP-1029 > > > >> > https://issues.apache.org/jira/browse/BIGTOP-1042 > > > >> > In fact, chances are both of them could end up > > > >> > in something like Bigtop 0.8.0 > > > >> > > > > > > > > > > > > > > > > -- > > > > Best regards, > > > > > > > > - Andy > > > > > > > > Problems worthy of attack prove their worth by hitting back. - Piet > > Hein > > > > (via Tom White) > > > > > > > > > > > > > > > > -- > > > Best regards, > > > > > > - Andy > > > > > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > > > (via Tom White) > > > > > > -- > Best regards, > > - Andy > > Problems worthy of attack prove their worth by hitting back. - Piet Hein > (via Tom White)
