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 Plain View
Hadoop >> mail # dev >> [PROPOSAL] change in bylaws to remove Release Plan vote


+
Matt Foley 2013-05-21, 21:10
+
Suresh Srinivas 2013-05-21, 21:48
+
Alejandro Abdelnur 2013-05-21, 22:18
+
Chris Douglas 2013-05-21, 21:37
+
Aaron T. Myers 2013-05-21, 21:45
+
Steve Loughran 2013-05-22, 10:53
+
Giridharan Kesavan 2013-05-21, 22:21
+
Eli Collins 2013-05-21, 23:02
+
Jitendra Pandey 2013-05-21, 23:13
+
Karthik Kambatla 2013-05-21, 23:48
+
Mahadev Konar 2013-05-22, 00:33
+
Matt Foley 2013-05-22, 01:57
+
Mattmann, Chris A 2013-05-22, 01:58
+
Matt Foley 2013-05-22, 02:01
+
Konstantin Shvachko 2013-05-22, 18:20
+
Matt Foley 2013-05-22, 19:39
+
Sandy Ryza 2013-05-21, 23:10
+
Arun C Murthy 2013-05-21, 23:00
+
Jagane Sundar 2013-05-21, 22:47
+
Matt Foley 2013-05-22, 02:06
+
Steve Loughran 2013-05-22, 10:52
+
Matt Foley 2013-05-22, 19:50
Copy link to this message
-
RE: [PROPOSAL] change in bylaws to remove Release Plan vote
Thanks for highlighting my concern, Matt.

I do not profess to great wisdom in the mechanisms of planning for, developing and putting out stable releases of Hadoop.

My point of view is quite simple, and pardon me for stating the obvious: A thriving Hadoop community is more that the developers of core HDFS and YARN - it includes the users of Hadoop, it includes the developers who write applications for Hadoop, it includes projects such as HBase that build on top of Hadoop, it includes commercial vendors who package Hadoop as part of their Big Data solutions, it includes vendors such as ourselves who build proprietary functionality on top of Hadoop, it includes OS vendors who want to bundle Hadoop as part of their Operating Systems.

Again - stating the obvious: For such a community to thrive and grow, a limited number of stable releases, along with a limited number of development branches where strong multi-company development takes place is crucial. There are a number of alternative technologies such as riak, mongoDB, memcache, MapR, etc. that are well funded and eager to overtake Hadoop, should Hadoop fragment.

Hopefully, the collective wisdom of the Hadoop PMC will play the benevolent dictator role that Linus plays so well for Linux.

I will stop here, since nobody ever reads more than four sentences of any email....

Jagane

-----Original Message-----
From: Matt Foley [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 22, 2013 12:51 PM
To: [EMAIL PROTECTED]
Subject: Re: [PROPOSAL] change in bylaws to remove Release Plan vote

Hi Jagane,
My response to your concerns is that I hope the PMC will have enough wisdom not to pass votes for a confusing number of releases -- if only to avoid the kind of fragmentation you point out could happen.

To date, however, this does not seem to have been a major problem in our community.  Indeed, lack of regularity in release schedules is more often cited as a problem. (Which this amendment is orthogonal to, so please start a different discussion thread if anyone wants to get into that issue! :-)

Thanks,
--Matt
On Wed, May 22, 2013 at 3:52 AM, Steve Loughran <[EMAIL PROTECTED]>wrote:

> On 21 May 2013 23:47, Jagane Sundar <[EMAIL PROTECTED]> wrote:
>
> > I see one significant benefit to having Release Plan votes: Fewer
> releases
> > with more members of the community working on any given release.
> > In turn, fewer Hadoop releases implies less confusion for end users
> > attempting to download and use an Apache Hadoop release.
> >
> > If there are a dozen different releases of Apache Hadoop available
> > for download at the Apache Hadoop website, end users will go to a
> > commercial vendor packaged version of Hadoop. That is not good for
> > the Apache Hadoop community as a whole.
> >
> > Jagane
> >
>
> I agree we don't want fragmentation; you don't want to have to choose
> between hadoop-2.1, hadoop-2.1.stevel-may and hadoop-2.1.stevel-june.
>
> With a vote on artifact releases, this can be prevented. I am free to
> create my -may and -june artifacts, but the PMC -it is just the PMC
> right?- get to say "no steve, you can't ship this from the apache.org"
> site, though I am free to make my own (which I have done in the past &
> put into my own RPMs. No need for a vote if I do it on my own site,
> though I did make sure I named the JARs and RPMs something else so
> that maven builds didn't get confused.
>
+
Arpit Gupta 2013-05-21, 22:21
+
Jonathan Eagles 2013-05-22, 14:07
+
Ravi Sharma 2013-05-22, 14:09
+
Tom White 2013-05-22, 14:58
+
Chris Nauroth 2013-05-22, 17:00
+
Roman Shaposhnik 2013-05-22, 17:04
+
Arpit Agarwal 2013-05-22, 17:14
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