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

Switch to Threaded View
Hadoop >> mail # dev >> [PROPOSAL] change in bylaws to remove Release Plan vote

Copy link to this message
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! :-)

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.