Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 matei@eecs.berkeley.edu does not designate 169.229.218.146 as permitted
 sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: [VOTE] Release candidate 0.20.203.0-rc1
From: Matei Zaharia <matei@eecs.berkeley.edu>
In-Reply-To: <BANLkTi=vjd_1yBdyudvt3Bk4rFKA2fe0Og@mail.gmail.com>
Date: Wed, 4 May 2011 23:21:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB428114-99DC-4687-A1F0-952700BB21DA@eecs.berkeley.edu>
References: <BANLkTik5gj0H4gmvy14Ux=g_r5Tt6D1=MA@mail.gmail.com>
 <C9E71BE8.19FCF%sureshms@yahoo-inc.com>
 <BANLkTikrS9PTeErT15fs2yv+N4_wpPN7xQ@mail.gmail.com>
 <BANLkTimjxRdf6PyTnbZUwrS_znZo00z-5w@mail.gmail.com>
 <BANLkTi=pNF_aQrWPurfXRbjNdshfseNobg@mail.gmail.com>
 <321761.51699.qm@web65903.mail.ac4.yahoo.com>
 <CB238EE8-1E06-4C6C-A7F5-CB00E2E073CB@yahoo-inc.com>
 <BANLkTi=aW6Toxtg7g=nFSV7h4gK68522wg@mail.gmail.com>
 <B746E44F-B6B3-40F2-BF75-C923E9B3962E@yahoo-inc.com>
 <BANLkTinvH8uUAzOQUogqnBanioPZ3UmnHg@mail.gmail.com>
 <BANLkTineZVMp1Fgv+JFT7NNihvDeHxdrvA@mail.gmail.com>
 <BANLkTimpuUhDRL1S4iYQKp3A-eKWcHi8kg@mail.gmail.com>
 <79A1AED5-9005-4F58-BFDB-F7394CB2A69C@gbiv.com>
 <89EC003F-E125-44C5-932C-2157A307CFD6@mac.com>
 <BANLkTinsQWnrZBUA0=--5Z4WJ7Y1jTRFcQ@mail.gmail.com>
 <BANLkTi=vjd_1yBdyudvt3Bk4rFKA2fe0Og@mail.gmail.com>
To: general@hadoop.apache.org

I'm not going to cast a vote, but I'm concerned about this for the same =
reasons Eli brought up -- in particular, compatibility with 0.22. I'm an =
author of several patches that have gone into 0.21 and trunk, only to =
stay on hiatus for 2 years because the project hasn't made a stable =
release since 0.20. (Today, many of these patches are being used through =
CDH, which is great, but it would be nice to see them in an Apache =
release too.) This push of features into 0.20.203 makes a widely used =
0.22 seem even more distant. Can we at least get a confirmation that =
these changes will be included in 0.22, as well as a timeline?

To support a vibrant developer community, Apache Hadoop should not just =
be a mechanism for Yahoo and Cloudera to publish patches. It should =
include a well-defined process for smaller third-party contributors to =
push changes that will make it into a stable release within a reasonable =
time horizon. The lack of such a process has been a major cause for the =
slowdown in the project in my perspective.

Matei


On May 4, 2011, at 10:47 PM, Eric Sammer wrote:

> (non-binding) -1 for similar reasons to what Jeff and others have laid =
out,
> and certainly if we're going to change the development process as a =
side
> effect of a release vote.
>=20
> On Wed, May 4, 2011 at 9:54 PM, Jeff Hammerbacher =
<hammer@cloudera.com>wrote:
>=20
>> -1.
>>=20
>> As Roy says, "whatever gets released will define the new norm by =
which
>> policies are assumed", and I certainly don't want this project to =
change
>> its
>> norms to accommodate bad practices. In particular, Eli presented =
three very
>> reasonable technical objections to this release. To summarize:
>>=20
>> 1) Let's get the JIRAs that are going into this release into trunk =
first.
>> 2) Let's create a JIRA for each issue in the release.
>> 3) Let's stick to the release numbering conventions established for =
this
>> project.
>>=20
>> I know the folks at Yahoo! are all professional engineers and done
>> tremendous work to help get the project to this point. There's no =
doubt in
>> my mind they understand the validity of the above three technical
>> objections. In fact, many of them helped author our "How to =
Contribute"
>> page, which established these conventions:
>> wiki.apache.org/hadoop/HowToContribute. We develop new features =
against
>> trunk, we create JIRAs for each issue, we review code before it goes =
into
>> trunk, and we only update old releases with bug fixes.
>>=20
>> I couldn't be more excited to have Yahoo! once again doing =
development in
>> Apache, and I hope that we can work together to get the work that =
you've
>> done in this branch into one of our upcoming feature releases.
>>=20
>> I hope those who voted +1 before Roy clarified what a release vote =
will
>> mean
>> for future project norms will reconsider their votes.
>>=20
>> While there may be many competing agendas in this community, we all =
wish to
>> see Apache Hadoop releases of the highest quality. Changing our norms =
to
>> allow huge, unreviewed patch sets introducing new features into a =
past
>> release is a step in the wrong direction.
>>=20
>> With a little bit of elbow grease, we can get the work done in this =
branch
>> into trunk, get 0.22 out the door, and be ready for a great 0.23 =
release.
>>=20
>> Later,
>> Jeff
>>=20
>> On Wed, May 4, 2011 at 9:17 PM, Nigel Daley <ndaley@mac.com> wrote:
>>=20
>>> I'm really not sure yet how to vote here.  I was going to vote +1 =
for
>> what
>>> I was told by a number of Yahoo! committers would be a one time =
release
>> as
>>> Yahoo! "comes back to Apache" after a hiatus last fall/winter and =
ended
>>> their own distribution.  Clearly this code was not all developed as =
a
>>> community process, but I was going to support a one time release of =
what
>>> they had developed in exclusion.
>>>=20
>>> Then I read Roy's email, which confused me.  We would he or I or =
anyone
>>> else support this release setting precedent or policy since it would =
walk
>>> all over our bylaws, community process, and the consensus nature of =
our
>>> foundation?  This release vote is a lazy majority of the PMC, but =
other
>>> decisions rolled up in this are supposed to be lazy majority of =
active
>>> committers or, in the case of code changes, a lazy consensus.  =
Setting
>>> policy by this release means any sufficiently large group of =
committers
>>> could go off and develop on their own and then commit it to a branch =
and
>>> call a release.
>>>=20
>>> Furthermore, it now sounds like this is possibly the first in a line =
of
>>> feature releases off this branch.  Bug fixes releases, sure.  But =
feature
>>> releases?  What's wrong with trunk?
>>>=20
>>> Nige
>>>=20
>>> On May 4, 2011, at 6:56 PM, Roy T. Fielding wrote:
>>>=20
>>>> On May 4, 2011, at 5:39 PM, Eli Collins wrote:
>>>>=20
>>>>> The point is that these discussion should be sorted out, ie you =
don't
>>>>> change your development and release model on a release VOTE =
thread,
>>>>> you change it on a DISCUSSION thread.
>>>>=20
>>>> That is no different than saying you have a right to veto a
>>>> release until the issue is addressed, which you don't have.
>>>>=20
>>>> A release vote is a majority decision.  If the majority
>>>> decides to release, then whatever gets released will define
>>>> the new norm by which policies are assumed.  If not released,
>>>> then I suggest collaborating more on the policies before
>>>> trying to vote again.
>>>>=20
>>>> Either way, we don't hold up a vote for the sake of a
>>>> policy discussion because voting is a more efficient
>>>> means of discovering if the policy really matters.
>>>>=20
>>>> ....Roy
>>>>=20
>>>=20
>>>=20
>>=20
>=20
>=20
>=20
> --=20
> Eric Sammer
> twitter: esammer
> data: www.cloudera.com