Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <878851.54111.qm@web65511.mail.ac4.yahoo.com>
Date: Mon, 2 May 2011 15:14:33 -0700 (PDT)
From: Andrew Purtell <apurtell@apache.org>
Reply-To: apurtell@apache.org
Subject: Re: [VOTE] Release candidate 0.20.203.0-rc0
To: general@hadoop.apache.org
In-Reply-To: <857369.41092.qm@web65511.mail.ac4.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I would like to make one minor but important clarification:=0A=0AFrom:=0A=
=0A> It would be regrettable if=0A> nontechnical factors ultimately prevent=
s Apache from=0A> incorporating the value of these contributions into an=0A=
> official release.=0A=0ATo:=0A=0AIt would be regrettable if nontechnical f=
actors ultimately prevents Apache from  incorporating the value of these co=
ntributions into an official release OF 0.20. There are some not yet ready =
to take the leap to 0.22; who do not consider it proven.  =0A=0ASo in this =
regard I do not wish to minimize concerns about distracting from the succes=
s of 0.22 or later releases. =0A=0A> From: Andrew Purtell <apurtell@apache.=
org>=0A> Subject: Re: [VOTE] Release candidate 0.20.203.0-rc0=0A> To: gener=
al@hadoop.apache.org=0A> Date: Monday, May 2, 2011, 3:05 PM=0A=0A> Most poi=
nts in this thread are valid,=0A> having to do with the process of how the =
contribution was=0A> assembled; and specific technical aspects of it, e.g. =
JIRAs=0A> missing from branch 0.20.203 relative to branch 0.20.=0A> However=
,=0A> =0A> > > From: Doug Cutting <cutting@apache.org>=0A> > > Assuming the=
 technical inconsistencies are sorted=0A> > > out, are you willing to withd=
raw you objection?=0A> > =0A> > These are not just technical concerns.=A0 H=
ow I vote on=0A> > any future release candidate will in part depend on how=
=0A> > the community is involved in its production.=0A> =0A> What strikes m=
e, as an observer to this discussion, is that=0A> here "community" does not=
 seem equated with Yahoo by=0A> implication. Perhaps I misread. Nevertheles=
s, Yahoo retains=0A> a good percentage of active Core developers with stand=
ing as=0A> both committers and high scale users, and these people=0A> produ=
ced the contribution that is branch 0.20.203, and=0A> therefore by definiti=
on "the community" was entirely=0A> involved in its production.=0A> =0A> Ya=
hoo should be commended for advancing the state of branch=0A> 0.20 with an =
obvious commitment to donating the results to=0A> Apache. As a community we=
 are lucky to have a strong=0A> contributor. Their security enhancements al=
low us and many=0A> others the option of strong authentication and user=0A>=
 isolation for multitenant deployments. =0A> =0A> A commercial vendor's pro=
duct already incorporates Yahoo's=0A> donated security enhancements. It wou=
ld be regrettable if=0A> nontechnical factors ultimately prevents Apache fr=
om=0A> incorporating the value of these contributions into an=0A> official =
release.=0A> =0A> Some technical concerns seem reasonable. Regarding that:=
=0A> =0A> > From: Stack <stack@duboce.net>=0A> > How hard would it be to ge=
t the patches Tom lists=0A> below into=0A> > branch-0.20-security-203?=A0 I=
'd think it'd be an=0A> easier=0A> > sell if it were a superset of all in 0=
.20, especially=0A> since it=0A> > bears its name.=0A> =0A> This suggestion=
 makes a lot of sense. In addition, filing=0A> JIRAs for and posting the di=
ffs of the remaining differences=0A> could help the process as well, and wo=
uld be good faith=0A> actions of an active contributor.=0A> =0A> Best regar=
ds,=0A> =0A> =A0 =A0 - Andy=0A> =0A> Problems worthy of attack prove their =
worth by hitting=0A> back. - Piet Hein (via Tom White)=0A> =0A>