Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: pass (athena.apache.org: domain of todd@cloudera.com designates
 209.85.161.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADY20s5ecshR4sO_YACSuBTswE2Di3WsYAOn27x=ecxUsOriFQ@mail.gmail.com>
References: 
 <CA+z3+9Fp0tHsyp8Yg2AqyjUkeuCRt3=p_rq54+M=bFPM9Cm-Fw@mail.gmail.com>
 <CAPn_vTtAos2QmVSXvGqh_7BgqeBmJ0vAqz21V_vnzkoXGFQrag@mail.gmail.com>
 <CADdVdVGp+X_G+J=qqT=MBxBNaP0i6PZNwBvArGiGUBTXGHEMfA@mail.gmail.com>
 <CAPn_vTtJGQK1hskWpi=dJwNyWwcWeqVKSkQSN+KQKdmmk0Cy9g@mail.gmail.com>
 <CA+z3+9HgArFJkNQ_QcTAu_F_Z45XgeXq3TGmUzBeyPsizJW01w@mail.gmail.com>
 <CADY20s5ecshR4sO_YACSuBTswE2Di3WsYAOn27x=ecxUsOriFQ@mail.gmail.com>
From: Todd Lipcon <todd@cloudera.com>
Date: Mon, 14 Nov 2011 13:44:24 -0800
Message-ID: 
 <CADY20s7JOxk_e4WzMhYdb+uscXa2jiaJFSJRP0CsXhGrpe4yDw@mail.gmail.com>
Subject: Re: [ANNOUNCE] Intend to build a 0.20.205.1 candidate next Friday 11
 Nov.
To: common-dev@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 11, 2011 at 2:29 PM, Todd Lipcon <todd@cloudera.com> wrote:
> On Fri, Nov 11, 2011 at 1:29 AM, Matt Foley <mfoley@hortonworks.com> wrot=
e:
>
>>
>> Also, I believe in the HDFS-2246 Jira, Todd requested extra time to revi=
ew,
>> due to commitments at Hadoop World. =A0Todd, would Monday be sufficient =
extra
>> time, so as not to slow down the anticipated release schedule too much?
>>
>
> Yes, I will probably have time to review it by Monday. But the
> review-time concern is separate from the concern about which version
> this should go into.
>

Reviewing this now... though I still think it shoudl target 0.20.206,
not 0.20.205.1.

-Todd

>
>>
>> On Thu, Nov 10, 2011 at 10:31 PM, Eli Collins <eli@cloudera.com> wrote:
>>
>>> Hey guys,
>>>
>>> HDFS-2246 is not a fix, it's a non-trivial performance optimization.
>>> The roadmap page is pretty clear.. =A0"Point releases are made to fix
>>> critical bugs. They do not introduce new features or make other
>>> improvements other than fixing bugs".
>>>
>>> I'm not opposed to the change, I'm just pointing out that we agreed to
>>> develop trunk first, and we agreed to follow the release policies for
>>> the sustaining branch. I don't see why we can't honor those
>>> agreements, ie why not post a patch for trunk first and then backport
>>> it to 206? Reasonable?
>>>
>>> Thanks,
>>> Eli
>>>
>>> On Thu, Nov 10, 2011 at 9:58 PM, Suresh Srinivas <suresh@hortonworks.co=
m>
>>> wrote:
>>> > Eli,
>>> >
>>> > As Jitendra indicated in the jira, this was originally supposed to be
>>> part
>>> > of 0.205. Due to time crunc, we could not get this done in 0.205. Thi=
s
>>> can
>>> > be turned off by a flag and only can be enabled by users who want to =
use
>>> > the functionality. Given that, I feel it is okay to go into 0.205.1.
>>> >
>>> > I agree it would be good to have a trunk patch for this and make it p=
art
>>> of
>>> > 0.23.
>>> >
>>> > Regards,
>>> > Suresh
>>> >
>>> > On Thu, Nov 10, 2011 at 4:32 PM, Eli Collins <eli@cloudera.com> wrote=
:
>>> >
>>> >> Hey Matt,
>>> >>
>>> >> Is HDFS-2246 slated for 0.20.205.1? =A0Given that it's not a bug and=
 is
>>> >> non-trivial it seems better suited for 206 than a point release. Als=
o,
>>> >> per the sustaining roadmap - http://wiki.apache.org/hadoop/Roadmap -
>>> >> "Only functionality already committed to trunk should be submitted t=
o
>>> >> a sustaining release." and this functionality does not yet have a
>>> >> patch for trunk yet (let alone committed).
>>> >>
>>> >> Thanks,
>>> >> Eli
>>> >>
>>> >> On Fri, Nov 4, 2011 at 5:56 PM, Matt Foley <mattf@apache.org> wrote:
>>> >> > Hi all,
>>> >> > I propose to make a 0.20.205.1 candidate soon, with the following
>>> sets of
>>> >> > patches:
>>> >> >
>>> >> > =A0 - deficiencies in HBase support, pointed out by the HBase team=
 and
>>> >> others
>>> >> > =A0 - deficiencies in webhdfs support on secure clusters
>>> >> > =A0 - a couple last-minute fixes submitted to branch-0.20-security=
-205
>>> that
>>> >> > =A0 were too late to be included in 205.0
>>> >> >
>>> >> > If you would like other patches included, and you feel it is
>>> appropriate
>>> >> to
>>> >> > have them in 205.1 rather than waiting for 206.0, please declare t=
hem
>>> by
>>> >> > setting the "Target Versions" field in their Jiras, and they will
>>> receive
>>> >> > due consideration, assuming that the proposed patch is actually
>>> >> > contributed, tested, reviewed, approved, and committed
>>> >> > to branch-0.20-security-205 by the freeze date :-)
>>> >> >
>>> >> > I would like to make the rc0 candidate next Friday, so I propose t=
o
>>> >> declare
>>> >> > 205.1 code freeze at noon, PST, Friday 11 Nov. =A0If this is a pro=
blem
>>> for
>>> >> > anyone, please let me know.
>>> >> >
>>> >> > Thank you, and best regards,
>>> >> > --Matt (Release Manager)
>>> >> >
>>> >>
>>> >
>>>
>>
>
>
>
> --
> Todd Lipcon
> Software Engineer, Cloudera
>


--=20
Todd Lipcon
Software Engineer, Cloudera