Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Bigtop >> mail # dev >> [DISCUSS] Setting up long term support mindset


Copy link to this message
-
Re: [DISCUSS] Setting up long term support mindset
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)
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB