Mailing-List: contact yarn-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-dev@hadoop.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 aw@altiscale.com does not designate 209.85.192.182 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?
From: Allen Wittenauer <aw@altiscale.com>
In-Reply-To: <D12373EF.14366%stevel@hortonworks.com>
Date: Mon, 9 Mar 2015 18:13:25 -0700
Cc: "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>
Content-Transfer-Encoding: quoted-printable
Message-Id: <40286DF5-3484-4F5F-A9F7-D0BD83845BDF@altiscale.com>
References: <D1235B6A.14259%stevel@hortonworks.com>
 <CA+qbEUNb1Y8zbrf_gkvaVcVKDQBX=CmOiexCyqWe8BDEH8HZQQ@mail.gmail.com>
 <CAGB5D2bk8ZtcqjqNKUsTJRm+b6EV=jyYLT=YPneyNQ_+J6hmaA@mail.gmail.com>
 <D12373EF.14366%stevel@hortonworks.com>
To: common-dev@hadoop.apache.org


	Between this and the other thread, I=92m seeing:

	* companies that were forced to make internal forks because =
their patches were ignored are now considered the deciders for whether =
we move forward
	* 5 years since the last branch off of trunk is considered =
=91soon=92
	* More good reasons to kill hadoop 2.7 and release hadoop 3.0 as =
the JDK7 release
	* We are now OPENLY hostile to operations teams
	* No one seems to really care that we=92re about to create an =
absolute nightmare for anyone that uses maven repos, as they=92ll need =
to keep track of which jars have been compiled with which JVM with zero =
hints from our build artifacts


On Mar 9, 2015, at 4:18 PM, Steve Loughran <stevel@hortonworks.com> =
wrote:

>=20
>=20
> On 09/03/2015 15:56, "Andrew Wang" <andrew.wang@cloudera.com> wrote:
>=20
>> I find this proposal very surprising. We've intentionally deferred
>> incompatible changes to trunk, because they are incompatible and do =
not
>> belong in a minor release. Now we are supposed to blur our eyes and
>> release
>> these changes anyway? I don't see this ending well.
>=20
> I'm staring at CHANGES.TXT & thinking 'how can we ship something off =
trunk
> that has as many of these as we can get out =8Bespecially those shell =
script
> bits=8B in a way that doesn't break everything. Because there's a lot =
of
> improvements and bug fixes there which aren't going to be anyone's =
hands
> for a long time otherwise, not just due to any proposed 3.x release
> schedule, but because of the java 8 requirements as well as =
classloader
> stuff.
>=20
>=20
>=20
>>=20
>> One higher-level goal we should be working towards is tightening our
>> compatibility guarantees, not loosening them. This is why I've been
>> highlighting classpath isolation as a 3.0 feature, since this is one =
of
>> the
>> biggest issues faced by our users and downstreams. I think a 3.0 with =
an
>> improved compatibility story will make operators and downstreams much
>> happier than releasing trunk as 2.8.
>>=20
>> Best,
>> Andrew
>=20
>=20
> I still want to see what's being proposed here. Having classpath =
isolation
> will make the JAR upgrade story in 3.x a lot cleaner, but we can't go =
to
> every app that imports hadoop-hdfs-client and say "your code just =
broke",
> not if they want their apps to continue to run on Hadoop 2 and/or Java =
7.
> Which, given that Java 7 is still something cluster ops teams are =
coming
> to terms with, is going to be a while
>=20
>=20
>>=20
>=20