You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Roman Shaposhnik <rv...@apache.org> on 2013/08/06 06:38:14 UTC
[DISCUSS] Bigtop "singularity" branch/release
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
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Roman Shaposhnik <rv...@apache.org>.
On Mon, Aug 5, 2013 at 9:51 PM, Konstantin Boudnik <co...@apache.org> 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 ;)
Well, that's the challenge, I suppose -- hence this thread ;-)
To some extent that's the exact same challenge that every
distribution faces and they all developed slightly different policies
as to how they approach stability vs. latest and greatest issue.
A canonical example here (pun intended) would be Ubuntu with
its LTS/regular releases.
I don't think Bigtop has had a chance to develop such a policy,
but perhaps now is time.
Finally, let me give you an example of one practical issue that
exists right now: as it happens, I'm very interested in integrating
at least Hadoop 2.1.x with HBase 0.96+. Also interested, but to
a somewhat lesser extent of throwing Hue 3.x and Oozie 4.x
into the same integration mix. From where I stand the options
I've got are essentially -- just doing it the branch without planning
any potential release vehicle or suggest those things for the BOM
of something like Bigtop 0.8.
Both options are fine, but I'd rather have others chime in
on which one they consider the most useful approach to the
problem at hand.
Thanks,
Roman.
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Roman Shaposhnik <rv...@apache.org>.
On Sun, Aug 11, 2013 at 1:17 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 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.
A strong +1 on the model described in the blog post -- a really solid
approach to engineering practices!
Thanks,
Roman.
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Konstantin Boudnik <co...@apache.org>.
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 <co...@apache.org> 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 <ap...@apache.org>
> > 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 <co...@apache.org>
> > 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)
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Andrew Purtell <ap...@apache.org>.
Replies inline, prefixed with [Andrew]
On Tue, Aug 6, 2013 at 9:39 PM, Konstantin Boudnik <co...@apache.org> 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 <ap...@apache.org>
> 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 <co...@apache.org>
> 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)
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Konstantin Boudnik <co...@apache.org>.
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).
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?
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 ;)
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 <ap...@apache.org> 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 <co...@apache.org> 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)
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Andrew Purtell <ap...@apache.org>.
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 <ap...@apache.org> 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 <co...@apache.org> 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)
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Andrew Purtell <ap...@apache.org>.
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 <co...@apache.org> 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)
Re: [DISCUSS] Bigtop "singularity" branch/release
Posted by Konstantin Boudnik <co...@apache.org>.
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