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
Hadoop >> mail # dev >> Re: Heads up - 2.0.5-beta


Copy link to this message
-
Re: Heads up - 2.0.5-beta
Hi Arun and Suresh,

I am glad my choice of words attracted your attention. I consider this
important for the project otherwise I wouldn't waste everybody's time.
You tend reacting on a latest message taken out of context, which does not
reveal full picture.
I'll try here to summarize my proposal and motivation expressed earlier in
these two threads:
http://s.apache.org/fs
http://s.apache.org/Streamlining

I am advocating
1. to make 2.0.5 a release that will
    a) make any necessary changes so that Hadoop APIs could be fixed after
that
    b) fix bugs: internal and those important for stabilizing downstream
projects
2. Release 2.1.0 stable. I.e. both with stable APIs and stable code base.
3. Produce a series of feature releases. Potentially catching up with the
state of trunk.
4. Release from trunk afterwards.

The main motivation to minimize changes in 2.0.5 is to let Hadoop users and
the downstream projects, that is the Hadoop community, to start adapting to
the new APIs asap. This will provide certainty that people can build their
products on top of 2.0.5 APIs with minimal risk the next release will break
them.
Thus Bobby in http://goo.gl/jm5am
is saying that the meaning of beta for him is locked down APIs for wire and
binary compatibility. For Hadoop Yahoo using 2.x is an opportunity to have
it tested at very large scale, which in turn will bring other users on
board.

I agree with Arun that we are not disagreeing on much. Just on the order of
execution: what goes first stability or features.
I am not challenging any features, the implementations, or the developers.
But putting all changes together is destructive for the stability of the
release. Adding a 500 KB patch invalidates prio testing solely because it
is a big change that needs testing not only by itself but with upstream
applications.
With 2.0.3 , 2.0.4 tested thoroughly and widely in many organizations and
several distributions it seems like a perfect base for the stable release.
We could be just two steps away from it.

I tried to explained as good as I could what I suggest, why, and why now. I
am not here to police, claim, mandate, enforce edicts, be a gatekeeper,
narrow view, tie up knots ... (did I miss any). If we disagree let's do it
by the rules we created for ourselves and move on. Life will self-adjust
and the entropy will keep increasing no matter what.

Thanks,
--Konstantin
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