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: [VOTE] - Release 2.0.5-beta


Copy link to this message
-
Re: [VOTE] - Release 2.0.5-beta
On Wed, May 15, 2013 at 9:25 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> The other thread or "vote" or whatever at least served the purpose in fresh
> surfacing of concerns. Talk of new features going in to a "beta" on a very
> short short timetable is concerning for anyone with experience working on
> large software projects. It's not a little ironic that this vote thread,
> done in response to sort out the other one predicated on stability
> concerns, begins with a laundry list of features and JIRAs to go in. I
> think it is usually the case that a beta release receives only bugfixes*
> over the alpha that proceeded it. This may just be a lack of consensus on
> what "beta" means.
>

Assuming that you are talking about HDFS features when you say
"features going into a beta on a very short short timetable" and
"laundry list" etc, I request you to take a cursory look at the development
of these features.

Snapshot is being developed since 2012 Nov, excluding the early
prototype that happened in 2012 May. Most of the development
was complete by the early February except for the support of rename
capability, which has been tricky. As regards to Windows support, this is a
work that has been happening for more than an year in many other branches.

So these features are not something that are impulsively developed
and irresponsibly pushed to a release. They have gone through
considerable testing and have been developed over a long time.

>
> Please set aside discussion on particular features or Hadoop bylaws or
> politics or debate club. I can't speak for all of downstream of course, but
> to the extent that I can I can say we don't care about that. The core ask,
> at least mine, is take a fresh look at reducing per-release disruptions to
> the rest of the entire ecosystem that has grown up around Hadoop.
What is the disruption you anticipate due to the current content of
the release?

If it is stability, I am confident that very few bugs will come out
of these features and stability should not be affected. This has been
the case for the HDFS features for many years. The development
is generally done in a feature branch, the feature is tested and stabilized
in that branch before merging to trunk. This is contrary to few people's
incorrect claims about how it has taken a long time to stabilize an HDFS
features in branch-2.

Needless to say stability is not just a concern of downstream projects. We
spend long hours, day in day out, trying to ensure features are stable as
core contributors.

Regards,
Suresh
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