Allen Wittenauer created HADOOP-11662:
-
Summary: trunk's CHANGES.txt is missing releases
Key: HADOOP-11662
URL: https://issues.apache.org/jira/browse/HADOOP-11662
Project: Hadoop Common
Masatake Iwasaki created HADOOP-11663:
-
Summary: Remove description about Java 6 from docs
Key: HADOOP-11663
URL: https://issues.apache.org/jira/browse/HADOOP-11663
Project: Hadoop Common
+1
On Mon, Mar 2, 2015 at 3:19 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
Hi devs,
It's been a year and a half since 2.x went GA, and I think we're about due
for a 3.x release.
Notably, there are two incompatible changes I'd like to call out, that will
have a tremendous positive
+1, this sounds like a good plan to me.
Thanks a lot for volunteering to take this on, Andrew.
Best,
Aaron
On Mon, Mar 2, 2015 at 3:19 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
Hi devs,
It's been a year and a half since 2.x went GA, and I think we're about due
for a 3.x release.
Hi devs,
It's been a year and a half since 2.x went GA, and I think we're about due
for a 3.x release.
Notably, there are two incompatible changes I'd like to call out, that will
have a tremendous positive impact for our users.
First, classpath isolation being done at HADOOP-11656, which has
Thanks Andrew for the proposal.
+1, and I will be happy to help.
--Yongjun
On Mon, Mar 2, 2015 at 3:19 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
Hi devs,
It's been a year and a half since 2.x went GA, and I think we're about due
for a 3.x release.
Notably, there are two
Andrew
Thanks for bringing up the issue of moving to Java8. Java8 is important
However, I am not seeing a strong motivation for changing the major number.
We can go to Java8 in the 2.series.
The classpath issue for Hadoop-11656 is too minor to force a major number
change (no pun intended).
Second, bumping the source and target JDK version to JDK8 (related to
HADOOP-11090), which is important since JDK7 is EOL in April 2015 (two
months from now). In the past, we've had issues with our dependencies
discontinuing support for old JDKs, so this will future-proof us.
Is moving to
+1 Happy to help too
On Mon, Mar 2, 2015 at 3:57 PM, Yongjun Zhang yzh...@cloudera.com wrote:
Thanks Andrew for the proposal.
+1, and I will be happy to help.
--Yongjun
On Mon, Mar 2, 2015 at 3:19 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
Hi devs,
It's been a year and a
JDK8 support is in the consideration, looks like many issues were reported and
resolved already.
https://issues.apache.org/jira/browse/HADOOP-11090
-Original Message-
From: Andrew Wang [mailto:andrew.w...@cloudera.com]
Sent: Tuesday, March 03, 2015 7:20 AM
To:
Is it interested to get the following issues in the release ? Thanks !
HADOOP-10670
HADOOP-10671
Regards,
Kai
-Original Message-
From: Yongjun Zhang [mailto:yzh...@cloudera.com]
Sent: Monday, March 02, 2015 4:46 AM
To: hdfs-...@hadoop.apache.org
Cc: Vinod Kumar Vavilapalli; Hadoop
Seems like there is already some action on the JIRA. Can you please ping the
previous reviewers on JIRA to make progress?
Thanks,
+Vinod
On Mar 1, 2015, at 12:45 PM, Yongjun Zhang
yzh...@cloudera.commailto:yzh...@cloudera.com wrote:
Hi,
Thanks for working on 2.7 release.
Currently the
On Mon, Mar 2, 2015 at 11:29 AM, Vinod Kumar Vavilapalli
vino...@hortonworks.com wrote:
We always needed another committer's +1 even if it isn't that clear in the
bylaws. In the minimum, we should codify this in the bylaws to avoid stuff
like people committing their own patches.
Regarding
Sorry for the bad. I thought it was sending to my colleagues.
By the way, for the JDK8 support, we (Intel) would like to investigate further
and help, thanks.
Regards,
Kai
-Original Message-
From: Zheng, Kai
Sent: Tuesday, March 03, 2015 8:49 AM
To: common-dev@hadoop.apache.org;
[
https://issues.apache.org/jira/browse/HADOOP-11449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran resolved HADOOP-11449.
-
Resolution: Fixed
Fix Version/s: 2.7.0
Assignee: Chris Nauroth (was:
+1
Regards,
Yi Liu
-Original Message-
From: Andrew Wang [mailto:andrew.w...@cloudera.com]
Sent: Tuesday, March 03, 2015 7:20 AM
To: common-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org;
hdfs-...@hadoop.apache.org; yarn-...@hadoop.apache.org
Subject: Looking to a Hadoop 3
+1 non-binding
It is a nice to have hadoop 3.x release. My honor to help.
Regards!
Chen
On Mon, Mar 2, 2015 at 4:58 PM, Zheng, Kai kai.zh...@intel.com wrote:
Sorry for the bad. I thought it was sending to my colleagues.
By the way, for the JDK8 support, we (Intel) would like to investigate
Andrew,
Thanks for bringing up this discussion.
I'm a little puzzled for I feel like we are rehashing the same discussion from
last year - where we agreed on a different course of action w.r.t switch to
JDK7.
IAC, breaking compatibility for hadoop-3 is a pretty big cost - particularly
for
I'm +1 for a migrate to Java 8 as soon as possible.
That's branch-2 trunk, as having them on the same language level makes
cherrypicking stuff off trunk possible. That's particularly the case for Java 8
as it is the first major change to the language since Java 5.
w.r.t shipping trunk as 3.x,
Kai, please ping the reviewers that were already looking at your patches
before. If the patches go in by end of this week, we can include them.
Thanks,
+Vinod
On Mar 2, 2015, at 7:04 PM, Zheng, Kai kai.zh...@intel.com wrote:
Is it interested to get the following issues in the release ? Thanks
+1
It sounds like a good idea, especially regarding JDK.
Regards
JB
On 03/03/2015 12:19 AM, Andrew Wang wrote:
Hi devs,
It's been a year and a half since 2.x went GA, and I think we're about due
for a 3.x release.
Notably, there are two incompatible changes I'd like to call out, that will
Thanks as always for the feedback everyone. Some inline comments to Arun's
email, as his were the most extensive:
Given that we already agreed to put in JDK7 in 2.7, and that the
classpath is a fairly minor irritant given some existing solutions (e.g. a
new default classloader), how do you
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?
I think 2.7 is needed at least as a stabilization step for the 2.x line.
2. If Hadoop 3 and 2.x are meant to exist together, we run a risk to
manifest
Vinod,
I agree that triviality is hard to define and we should not add things that
can be interpreted multiple ways to the bylaws.
If something is not quite clear in the bylaws, it would make sense to have
a proposal of new phrasing, so that we could discuss it here and call a
vote upon reaching
See https://builds.apache.org/job/Hadoop-common-trunk-Java8/122/changes
Changes:
[aajisaka] HDFS-5853. Add hadoop.user.group.metrics.percentiles.intervals to
hdfs-default.xml (aajisaka)
[ozawa] HADOOP-11634. Description of webhdfs' principal/keytab should switch
places each other. Contributed
Gera Shegalov created HADOOP-11659:
--
Summary: o.a.h.fs.FileSystem.Cache#remove should use a single hash
map lookup
Key: HADOOP-11659
URL: https://issues.apache.org/jira/browse/HADOOP-11659
Project:
Edward Nevill created HADOOP-11660:
--
Summary: Add support for hardware crc on ARM aarch64 architecture
Key: HADOOP-11660
URL: https://issues.apache.org/jira/browse/HADOOP-11660
Project: Hadoop Common
I agree with Andrew and Konst here. I don't think the language is
unclear in the rule, either... consensus with a minimum of one +1
clearly indicates that _other people_ are involved, not just one
person.
I would also mention that we created the branch committer role
specifically to make it
Thanks for bringing this up. If you can find any place where an array
might realistically be larger than 67 million elements, then I guess
file a JIRA for it. Also this array needs to be of objects, not of
primitives (quicksort is used for those in jdk7, apparently). I can't
think of any such
We always needed another committer's +1 even if it isn't that clear in the
bylaws. In the minimum, we should codify this in the bylaws to avoid stuff like
people committing their own patches.
Regarding trivial changes, I always distinguish between trivial *patches* and
trivial changes to
Brahma Reddy Battula created HADOOP-11661:
-
Summary: Deprecate FileUtil#copyMerge
Key: HADOOP-11661
URL: https://issues.apache.org/jira/browse/HADOOP-11661
Project: Hadoop Common
31 matches
Mail list logo
