Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - [DISCUSS] Spin out MR, HDFS and YARN as their own TLPs and disband Hadoop umbrella project


Copy link to this message
-
Re: [DISCUSS] Spin out MR, HDFS and YARN as their own TLPs and disband Hadoop umbrella project
Andrew Purtell 2012-08-31, 06:42
If Apache Hadoop -- as an umbrella or sum of its parts -- isn't practical
to develop end applications or downstream projects on, the community will
disappear. I don't follow your logic. I deal with the technical realities
of actually trying to use an Apache Hadoop distribution, the pieces
released as source from the ASF, directly in production, and your position
is dismissive if not hostile to my concerns as an end user. What
"community" do you mean then? Vendors? Academics? People who like to tinker
with things they can't actually use?

And you can't just hand waive that this will all work out if done RIGHT
NOW, especially with something as inelegant as a SVN copy.

On Friday, August 31, 2012, Mattmann, Chris A (388J) wrote:

> Hi Andrew,
>
> How many new Apache Foundation *members* has the Hadoop PMC added over the
> past
> 3-4 years, and by whom (the answer to this question might surprise you)?
>
> The thing you and others continue not to see is that the ASF isn't about
> the
> most superior technical solutions, or the best refactorings to prevent
> Google Guava
> dependencies, the ASF is about *community* _over_ *code*.
>
> Period. The metrics that the Foundation and its members are interested in
> are
> the metrics that demonstrate the health of the project. Technical prowess
> and
> market-share are great, as are diverse, hungry, downstream user
> communities.
> But the ASF is here to create communities, communities that work together
> to
> develop code for public good at no charge to the public. Scope out Board
> resolutions to create projects and read the repetitive text in them --
> there's a
> pattern there that elucidates this.
>
> Also, the project members and community members here could slice and
> dice the project into 50 different Top Level Projects, but it doesn't mean
> that
> Hadoop would be at its "ending".
>
> Cheers,
> Chris
>
>
> On Aug 30, 2012, at 11:02 PM, Andrew Purtell wrote:
>
> > Looking at the voting, it appears YARN wants to become a TLP RIGHT NOW
> but
> > at the price of the complete decoherence of the Apache Hadoop platform.
> For
> > all of us who have invested in the Apache Hadoop platform, how does this
> > benefit us? Certainly our interests seem to get little consideration with
> > this plan to just blow everything up tomorrow.
> >
> > How does a downstream project that imports HDFS and MapReduce coordinate
> > the shared dependencies with those new projects? For, example Guava. One
> > could have a multi way library incompatibility problem; this has already
> > happened in the large with HDFS, HBase, and Pig. It's DLL hell magnified
> 3
> > or 4 times just in the smoking ruins of "core". The obvious answer is:
> Once
> > these pieces are moving in different trajectories at different rates, end
> > users and downstream projects will be forced to negotiate with many
> > parties, and those parties explicitly wont care about the issues
> concerning
> > another, according to this discussion. YARN must have broken our
> > minicluster based MapReduce tests 5 times over the last year. HDFS took
> up
> > a certain version of Guava and this required us to refactor some code to
> > match that version. We had a coherent group of committers to assist us
> then
> > but that would go away. Proponents of the split seem to want exactly this
> > situation. BigTop was suggested as a vehicle for addressing that concern
> > but then explicitly rejected on this thread. A commercial vendor looking
> to
> > torpedo the ability of anyone to build something on Apache Hadoop
> directly
> > couldn't come up with a better plan, because only a full time operation
> can
> > be expected to have the resources to harmonize the pieces plus all of
> their
> > dependencies with build patches, code wrangling, testing, testing,
> testing.
> > Volunteer contributor and committer time is a precious gift. I wonder if
> > the many professional full time Hadoop devs voting here have lost sight
> of
> > this. Pushing your integration work downstream doesn't mean resources

Best regards,

   - Andy

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