Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: [Release thread] 2.6.5 release activities
MIME-Version: 1.0
From: Junping Du <jdu@hortonworks.com>
To: Allen Wittenauer <aw@effectivemachines.com>
CC: "common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>,
	"yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Thread-Topic: [Release thread] 2.6.5 release activities
Thread-Index: AQHR8p65odIp3D+jeEesn+l78eYEmaBCw9UA//+WW7mAAMIBgIAAl3YBgACRe4D//4yWPQ==
Date: Thu, 11 Aug 2016 15:10:53 +0000
Message-ID: <1470928427902.19947@hortonworks.com>
References: <CAPz5eN7uUTAxNOUimao+hzx0hjwzVfZZz=vQE4PCVjimu8SSVQ@mail.gmail.com>
 <613605965.12351946.1470842058395.JavaMail.yahoo@mail.yahoo.com>
 <1470847185717.28914@hortonworks.com>
 <CAPz5eN6JVis5tKkVoPv1n=Low64AYOnMBU6w35tn31qDZWW6YA@mail.gmail.com>
 <1470920528790.43548@hortonworks.com>,<1D457905-E069-4DD0-AE8A-CDB38EECC47D@effectivemachines.com>
In-Reply-To: <1D457905-E069-4DD0-AE8A-CDB38EECC47D@effectivemachines.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
archived-at: Thu, 11 Aug 2016 15:11:08 -0000

Allen, to be clear, I am not against any branch release effort here. Howeve=
r, as RM for previous releases 2.6.3 and 2.6.4, I feel to have responsibili=
ty to take care branch-2.6 together with other RMs (Vinod and Sangjin) on t=
his branch and understand current gap - especially, to get consensus from c=
ommunity on the future plan for 2.6.x.
Our bylaw give us freedom for anyone to do release effort, but our bylaw do=
esn't stop our rights for reasonable question/concern on any release plan. =
As you mentioned below, people can potentially fire up branch-1 release eff=
ort. But if you call a release plan tomorrow for branch-1, I cannot imagine=
 nobody will question on that effort. Isn't it?=20
Let's keep discussions on releasing 2.6.5 more technical. IMO, to make 2.6.=
5 release more reasonable, shouldn't we check following questions first?
1. Do we have any significant issues that should land on 2.6.5 comparing wi=
th 2.6.4?
2. If so, any technical reasons (like: upgrade is not smoothly, performance=
 downgrade, incompatibility with downstream projects, etc.) to stop our use=
rs to move from 2.6.4 to 2.7.2/2.7.3?
I believe having good answer on these questions can make our release plan m=
ore reasonable to the whole community. More thoughts?

Thanks,

Junping
________________________________________
From: Allen Wittenauer <aw@effectivemachines.com>
Sent: Thursday, August 11, 2016 3:13 PM
To: Junping Du
Cc: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev=
@hadoop.apache.org; yarn-dev@hadoop.apache.org
Subject: Re: [Release thread] 2.6.5 release activities

> On Aug 11, 2016, at 5:59 AM, Junping Du <jdu@hortonworks.com> wrote:
>
>      These comments are more like wishes but not giving more clarificatio=
ns on the needs. I would like to hear more specific reasons to not move to =
2.7.x releases but prefer to upgrade to 2.6.5. If the only reason is about =
expectation management, I think we should claim 2.6.5 is the last branch-2.=
6 release after this release work, otherwise people would expect us to main=
tain this branch forever which is impossible and unnecessary. Thoughts?

        The bylaws[*] are such that if community members want to spend thei=
r time working on a branch, there isn't much to prevent that other than the=
 PMC voting down the release of that branch or removing the committers work=
ing on that branch.  As has been pointed out to me many times, one can't di=
ctate where others spend their volunteer time.  If they want to spend their=
 efforts on branch-2.6, they can.  If that comes at the detriment of releas=
es around branch-2.7 or branch-2.8 or even trunk, then so be it. Technicall=
y, someone could still fire up a branch-1 release.  Given the numbers of co=
mmitters and PMC members as listed on the main ASF website (not the list on=
 project one), we should have more than enough people to do all this work a=
nyway.

* - of course, there's a few bylaws that aren't really enforced, so maybe e=
ven this isn't true?

---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-dev-help@hadoop.apache.org