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 > > <[email protected]<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)
signature.asc
Description: Digital signature
