Return-Path: X-Original-To: apmail-bigtop-user-archive@www.apache.org Delivered-To: apmail-bigtop-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 12357DE9D for ; Thu, 7 Mar 2013 04:38:34 +0000 (UTC) Received: (qmail 7816 invoked by uid 500); 7 Mar 2013 04:38:33 -0000 Delivered-To: apmail-bigtop-user-archive@bigtop.apache.org Received: (qmail 7600 invoked by uid 500); 7 Mar 2013 04:38:32 -0000 Mailing-List: contact user-help@bigtop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@bigtop.apache.org Delivered-To: mailing list user@bigtop.apache.org Received: (qmail 7565 invoked by uid 99); 7 Mar 2013 04:38:31 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Mar 2013 04:38:31 +0000 Received: from localhost (HELO mail-vb0-f52.google.com) (127.0.0.1) (smtp-auth username apurtell, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 07 Mar 2013 04:38:31 +0000 Received: by mail-vb0-f52.google.com with SMTP id fa15so22022vbb.11 for ; Wed, 06 Mar 2013 20:38:30 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.58.205.179 with SMTP id lh19mr12633739vec.7.1362631110117; Wed, 06 Mar 2013 20:38:30 -0800 (PST) Received: by 10.58.128.170 with HTTP; Wed, 6 Mar 2013 20:38:29 -0800 (PST) In-Reply-To: References: <20130306181012.GD32399@tpx> Date: Thu, 7 Mar 2013 12:38:29 +0800 Message-ID: Subject: Re: [DISCUSS] Setting up long term support mindset From: Andrew Purtell To: "dev@bigtop.apache.org" Cc: "user@bigtop.apache.org" Content-Type: multipart/alternative; boundary=089e011841a0479bdd04d74e47a3 --089e011841a0479bdd04d74e47a3 Content-Type: text/plain; charset=ISO-8859-1 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 > > 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) --089e011841a0479bdd04d74e47a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A lot of behavior among loosely coupled projects is emergent. So in that se= nse some of what bigtop can produce is defined by something beyond direct c= ontrol. What you can do is try to influence the processes at work. So, outr= each to each component project. Also, constructive pressure. Publicize bigt= op as a vetted stable open packaging of Hadoop. Don't upgrade component= s if there is an integration issue and an unresponsive community. This woul= d apply constructive pressure on the unresponsive community commensurate wi= th the influence of bigtop.=A0

To grow the influence of bigtop, engaging vendors might be u= seful. For those pursuing an open strategy or open core strategy then commo= ditizing and amortizing the costs of baseline packaging and integration con= cerns makes sense. Everybody wins because more bandwidth is available to fo= cus on differentiators. Such vendors typically employ committers for commun= ity based development. If some of these=A0vendors can publicly=A0get behind= bigtop and invest in its credibility, then as an emergent consequence ther= e will be more community engagement on integration issues under its umbrell= a. Everyone will win.=A0

On some of the specific points, my humble opinion:

2. Hadoop 2 is the only long term viable option even i= f some parts may be still unstable in terms of API.=A0

3. This seems a case of "build it and they will come". Itera= te on a BOM that (mostly) works. Publicize it. For integration blockers, tr= ack the respective JIRAs on the bigtop wiki. Be polite. Be proactive. Mail = the respective dev lists with gentle reminders, but not too frequently.=A0<= /div>

4. See above.=A0

5. You can= 9;t.=A0

On Thursday, March 7, 2013, Roman Shaposhnik wrote:
On Wed, Mar 6, 2013 at 10:10 AM, Konstantin Boudnik <cos@a= pache.org> 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 ot= her
chime in on:
=A0 #1 I think it is too late to change the focus of Bigtop 0.6.0
=A0 #2 Do we have a reasonable conviction that the beta
=A0 =A0 =A0 =A0release of Hadoop 2.X is withing reach?
=A0 #3 How do we influence Hadoop community to help us
=A0 =A0 =A0 =A0produce the first ever LTS of Bigtop?
=A0 #4 How do we get the downstream communities (pig, oozie, etc)
=A0 =A0 =A0 =A0on-board so that we can all work towards this common goal? =A0 #5 Suppose we do all the work in all of the downstream components,
=A0 =A0 =A0 =A0how can we at least make sure that there will be patch
=A0 =A0 =A0 =A0releases 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,

=A0 =A0- Andy=

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

--089e011841a0479bdd04d74e47a3--