zhihai xu created MAPREDUCE-6269:
Summary: improve JobConf not to share Credentials between jobs by
default.
Key: MAPREDUCE-6269
URL: https://issues.apache.org/jira/browse/MAPREDUCE-6269
Project: Hado
Awesome, looks like we can just do this in a compatible manner - nothing else
on the list seems like it warrants a (premature) major release.
Thanks Vinod.
Arun
From: Vinod Kumar Vavilapalli
Sent: Tuesday, March 03, 2015 2:30 PM
To: common-...@hadoop.ap
I started pitching in more on that JIRA.
To add, I think we can and should strive for doing this in a compatible manner,
whatever the approach. Marking and calling it incompatible before we see
proposal/patch seems premature to me. Commented the same on JIRA:
https://issues.apache.org/jira/bro
Between:
* removing -finalize
* breaking HDFS browsing
* changing du’s output (in the 2.7 branch)
* changing various names of metrics (either intentionally or otherwise)
* changing the JDK release
… and probably lots of other stuff in branch-2 I hav
Totally agreed. I just left a comment there on the current state and what is
needed. As of now, I think the big (and only?) changes are flipping the default
classloader for tasks and splitting the HDFS jar.
Thanks,
+Vinod
On Mar 3, 2015, at 9:02 AM, Steve Loughran
mailto:ste...@hortonworks.com
> On Mar 3, 2015, at 9:36 AM, Karthik Kambatla wrote:
>
> If we preserve API compat and try to preserve wire compat, I don't see the
> harm in bumping the major release.
If we preserve compatibility, then there is no need to bump major number.
> It allows us to include several
> fixes/features
I am surprised classpath-isolation is being called a minor issue. We have
been hearing users complain about Hadoop leaking its dependencies into the
classpath for a while now, Guava being the culprit often. Not being able to
upgrade our dependencies without affecting users has started to hamper our
I want to understand a lot more about the classpath isolation (HADOOP-11656)
proposal, specifically, what is proposed and does it have to be tagged as
incompatible? That's a bigger change than must setting javac.version=8 in the
POM —though given what a fundamental problem it addresses, I'm in
Hi Junping, thanks for your response,
I view branch-3 as essentially the same size as our recent 2.x releases,
with the exception of incompatible changes like classpath isolation and
JDK8 target version. These, while perhaps not revolutionary, are still
incompatible, and require a major version bu
Hi Akira, thanks for responding,
On Tue, Mar 3, 2015 at 4:04 AM, Akira AJISAKA
wrote:
> Thanks Andrew for bringing this up.
> +1 mostly looks fine but I'm thinking it's not now to cut branch-3.
>
> > classpath isolation
>
> IMHO, classpath isolation is a good thing to do.
> We should pay down th
Hi Konst, thanks for taking a look. I think I essentially agree with your
points.
On Mon, Mar 2, 2015 at 11:04 PM, Konstantin Shvachko
wrote:
> Andrew,
>
> Hadoop 3 seems in general like a good idea to me.
> 1. I did not understand if you propose to release 3.0 instead of 2.7 or in
> addition?
>
See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/2071/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 31185 lines...]
Results :
Tests run: 519, Failures
See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Java8/121/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 10603 lines...]
Tests run: 522, Failures: 2, Er
Thanks all for good discussions here.
+1 on supporting Java 8 ASAP. In addition, I agree that we should separating
this effort with cutting down Hadoop 3.
IMO, Hadoop is still very cool today, and we should only consider Hadoop 3
until we have revolutionary feature (like YARN for 2.0) which dese
Hi all,
One year after the previous post, we collected and analyzed
JIRA tickets again to investigate the activities of Apache Hadoop
community in 2014.
http://ajisakaa.blogspot.com/2015/02/the-activities-of-apache-hadoop.html
As we expected in the previous post, the activities of
Apache Hadoop
Thanks Andrew for bringing this up.
+1 mostly looks fine but I'm thinking it's not now to cut branch-3.
> classpath isolation
IMHO, classpath isolation is a good thing to do.
We should pay down the technical dept ASAP. I'm willing to help.
I'm thinking we can cut branch-3 and release 3.0 alpha
16 matches
Mail list logo