Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
MIME-Version: 1.0
In-Reply-To: <568FE726.8000200@oss.nttdata.co.jp>
References: <2E87444F-47B4-4AE8-BDAA-CAE0CEE42A95@apache.org>
 <56783DD9.30900@oss.nttdata.co.jp>
 <CAD++eCk-yccaMHF_Kn7B0574f4UjshDRF3WSu8UoTZgh_4VS7w@mail.gmail.com>
 <CAAD07OJDNj1-_SwSo9BGpDeY09A6s3qMWs-n8JjvpCzqBRe-bQ@mail.gmail.com>
 <CAHzf5Bxu0aTuUSJEqNMmu8qRheG2sL439EdVv+zJPf_7VAZNrg@mail.gmail.com>
 <1450801895257.55510@hortonworks.com>
 <BEEDFD8F-DAE6-414B-B05F-CBAD362AD659@apache.org>
 <98FA2C03-CED8-4D15-B1A8-E6D370594FA4@apache.org>
 <1451401123108.24093@hortonworks.com>
 <568FE726.8000200@oss.nttdata.co.jp>
From: Andrew Wang <andrew.wang@cloudera.com>
Date: Fri, 8 Jan 2016 11:43:33 -0800
Message-ID: 
 <CAGB5D2ZKX28Wprp9mAVc_+7Ar4mDMgGZEAbSA5XLyJU=DTGfyQ@mail.gmail.com>
Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
To: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>
Cc: "mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
	Vinod Kumar Vavilapalli <vinodkv@apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c08863ea3022e0528d7ce9e

--94eb2c08863ea3022e0528d7ce9e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I like monotonic releases since it's simple for users to understand. Is it
difficult to backport to 2.7.x if you're already backporting to 2.6.x? I
don't follow why special casing some class of fixes is desirable.

Also for maintenance releases, aren't all included fixes supposed to be for
serious bugs? Minor JIRAs can wait for the next minor release. If there are
strong reasons to include a minor JIRA in a maintenance release, then maybe
it's not really a minor JIRA.

Best,
Andrew

On Fri, Jan 8, 2016 at 8:43 AM, Akira AJISAKA <ajisakaa@oss.nttdata.co.jp>
wrote:

> The general rule sounds good to me.
>
> > "any fix in 2.x.y to be there in all 2.b.c releases (while b>=3Dx) that
> get out after 2.x.y release date"
>
> +1
>
> > I would prefer this rule only applies on critical/blocker fixes, but no=
t
> applies on minor/trivial issues.
>
> +1
>
> Thanks,
> Akira
>
>
> On 12/29/15 23:50, Junping Du wrote:
>
>> I am +1 with pulling all of these tickets into 2.7.2.
>>
>> - For =E2=80=9Cany fix in 2.6.3 to be there in all releases that get out=
 after
>> 2.6.3 release date=E2=80=9D
>>
>> Shall we conclude this as a general rule - "any fix in 2.x.y to be there
>> in all 2.b.c releases (while b>=3Dx) that get out after 2.x.y release da=
te"?
>> I am generally fine with this, but just feel it sounds to set too strong
>> restrictions among branches. Some fixes could be trivial (test case fix,
>> etc.) enough to deserve more flexibility.=E2=80=8B I would prefer this r=
ule only
>> applies on critical/blocker fixes, but not applies on minor/trivial issu=
es.
>>
>> Just 2 cents.
>>
>>
>> Thanks,
>>
>>
>> Junping
>>
>>
>> ________________________________
>> From: Vinod Kumar Vavilapalli <vinodkv@apache.org>
>> Sent: Thursday, December 24, 2015 12:47 AM
>> To: Junping Du
>> Cc: mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org;
>> common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
>> Subject: Re: [VOTE] Release Apache Hadoop 2.7.2 RC1
>>
>> I retract my -1. I think we will need to discuss this a bit more.
>>
>> Beyond those two tickets, there are a bunch more (totaling to 16) that
>> are in 2.6.3 but *not* in 2.7.2. See this:
>> https://issues.apache.org/jira/issues/?jql=3Dkey%20in%20%28HADOOP-12526%=
2CHADOOP-12413%2CHADOOP-11267%2CHADOOP-10668%2CHADOOP-10134%2CYARN-4434%2CY=
ARN-4365%2CYARN-4348%2CYARN-4344%2CYARN-4326%2CYARN-4241%2CYARN-2859%2CMAPR=
EDUCE-6549%2CMAPREDUCE-6540%2CMAPREDUCE-6377%2CMAPREDUCE-5883%2CHDFS-9431%2=
CHDFS-9289%2CHDFS-8615%29%20and%20fixVersion%20!%3D%202.7.0
>> <
>> https://issues.apache.org/jira/issues/?jql=3Dkey%20in%20(HADOOP-12526,HA=
DOOP-12413,HADOOP-11267,HADOOP-10668,HADOOP-10134,YARN-4434,YARN-4365,YARN-=
4348,YARN-4344,YARN-4326,YARN-4241,YARN-2859,MAPREDUCE-6549,MAPREDUCE-6540,=
MAPREDUCE-6377,MAPREDUCE-5883,HDFS-9431,HDFS-9289,HDFS-8615)%20and%20fixVer=
sion%20!=3D%202.7.0
>> >
>>
>> Two options here, depending on the importance of =E2=80=98causality' bet=
ween
>> 2.6.x and 2.7.x lines.
>>   - Ship 2.7.2 as we voted on here
>>   - Pull these 16 tickets into 2.7.2 and roll a new RC
>>
>> What do people think? Do folks expect =E2=80=9Cany fix in 2.6.3 to be th=
ere in
>> all releases that get out after 2.6.3 release date (December 16th)=E2=80=
=9D?
>>
>> Thanks
>> +Vinod
>>
>> On Dec 23, 2015, at 12:37 PM, Vinod Kumar Vavilapalli <vinodkv@apache.or=
g
>> <mailto:vinodkv@apache.org>> wrote:
>>
>> Sigh. Missed this.
>>
>> To retain causality ("any fix in 2.6.3 will be there in all releases tha=
t
>> got out after 2.6.3=E2=80=9D), I=E2=80=99ll get these patches in.
>>
>> Reverting my +1, and casting -1 for the RC myself.
>>
>> Will spin a new RC, this voting thread is marked dead.
>>
>> Thanks
>> +Vinod
>>
>> On Dec 22, 2015, at 8:24 AM, Junping Du <jdu@hortonworks.com<mailto:
>> jdu@hortonworks.com>> wrote:
>>
>> However, when I look at our commit log and CHANGES.txt, I found somethin=
g
>> we are missing:
>> 1. HDFS-9470 and YARN-4424 are missing from the 2.7.2 branch and RC1 tag=
.
>> 2. HADOOP-5323, HDFS-8767 are missing in CHANGE.txt
>>
>>
>>
>

--94eb2c08863ea3022e0528d7ce9e--