There are two goals here & I'm not sure how they can be met with a single release. - Stabilizing Apache Hadoop 2.0 - Providing a known stable collection of hadoop components for hadoop users.
I support both goals, but I'm not sure how you'd base them on the same release... Currently my recommendation for anyone looking for the most stable release of hadoop is to use the 1.0 line. That may change in 2013, but that is not yet proven. I encourage folks to use 2.0, but with eyes open that they may cut their knuckles. Hadoop 2.0 is young. That's why it is tagged alpha. APIs are still changing for good reasons, which seems like more than a labeling problem to me. I certainly support the goal of a LTS on 2, but until the Hadoop PMC declares Hadoop 2.0 GA, my read is that anyone declaring that they are going to be LTS on 2.0 is betting that they understand Hadoop's stability better than the Hadoop PMC. But maybe I don't understand the intent of the LTS label? E14 On Mar 7, 2013, at 10:57 AM, Konstantin Boudnik <c...@apache.org> wrote: > Andrew, > I think the influence part is about how to make LTS accepted and not how to > make LTS happened, right? > > With respect to Roman's points: > > 1. Agree > > 2. a lot of people are keep using Hadoop-1 because of the perception that > Hadoop-2 is alpha. And the "alpha" tag helps a lot to keep this impression > hardened, IMO. So, it is quite critical to produce a stable Bigtop stack, > including a reasonably stable Hadoop. Beta is a good aim, I think > > 3. can be solved by having an RM for a Hadoop release combined with an RM for > BigTop release, who can coordinate the cross-effort. > > 4. The only way is to help these components be more comfortable with the base > of the stack. 2-3 above are addressing it, I believe. > > 5. I tend to agree with Andrew - it might be quite hard to do. > > Cos > > On Thu, Mar 07, 2013 at 12:38PM, Andrew Purtell wrote: >> A lot of behavior among loosely coupled projects is emergent. So in that >> sense some of what bigtop can produce is defined by something beyond direct >> control. What you can do is try to influence the processes at work. So, >> outreach to each component project. Also, constructive pressure. Publicize >> bigtop as a vetted stable open packaging of Hadoop. Don't upgrade >> components if there is an integration issue and an unresponsive community. >> This would apply constructive pressure on the unresponsive community >> commensurate with the influence of bigtop. >> >> To grow the influence of bigtop, engaging vendors might be useful. For >> those pursuing an open strategy or open core strategy then commoditizing >> and amortizing the costs of baseline packaging and integration concerns >> makes sense. Everybody wins because more bandwidth is available to focus on >> differentiators. Such vendors typically employ committers for community >> based development. If some of these vendors can publicly get behind bigtop >> and invest in its credibility, then as an emergent consequence there will >> be more community engagement on integration issues under its umbrella. >> Everyone will win. >> >> On some of the specific points, my humble opinion: >> >> 2. Hadoop 2 is the only long term viable option even if some parts may be >> still unstable in terms of API. >> >> 3. This seems a case of "build it and they will come". Iterate on a BOM >> that (mostly) works. Publicize it. For integration blockers, track the >> respective JIRAs on the bigtop wiki. Be polite. Be proactive. Mail the >> respective dev lists with gentle reminders, but not too frequently. >> >> 4. See above. >> >> 5. You can't. >> >> On Thursday, March 7, 2013, Roman Shaposhnik wrote: >> >>> On Wed, Mar 6, 2013 at 10:10 AM, Konstantin Boudnik >>> <c...@apache.org<javascript:;>> >>> wrote: >>>> I believe there's not much more to say about it, except that this is, >>>> in my opinion, a good way to establish our project as de-facto go-to >>>> place for community driven Hadoop based stacks and a focal point for >>>> the integration in the ASF storage and analytics projects. >>> >>> I like this idea very much! A couple of things that I'd love to hear other >>> chime in on: >>> #1 I think it is too late to change the focus of Bigtop 0.6.0 >>> #2 Do we have a reasonable conviction that the beta >>> release of Hadoop 2.X is withing reach? >>> #3 How do we influence Hadoop community to help us >>> produce the first ever LTS of Bigtop? >>> #4 How do we get the downstream communities (pig, oozie, etc) >>> on-board so that we can all work towards this common goal? >>> #5 Suppose we do all the work in all of the downstream components, >>> how can we at least make sure that there will be patch >>> releases incorporating all the changes we've done? >>> >>> Now, Bigtop (well, me personally at least ;-)) would be more than >>> willing to help on all of these with automation, testing, etc. But >>> we *have* to get all of the communities involved on-board with this. >>> >>> Thanks, >>> Roman. >>> >> >> >> -- >> Best regards, >> >> - Andy >> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein >> (via Tom White)
