Takuya Fukudome created HDFS-7872:
-
Summary: Erasure Coding: INodeFile.dumpTreeRecursively() supports
to print striped blocks
Key: HDFS-7872
URL: https://issues.apache.org/jira/browse/HDFS-7872
Projec
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 an
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 yo
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
mailto:yzh...@cloudera.com>> wrote:
Hi,
Thanks for working on 2.7 release.
Currently the fallback from KerberosA
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 wrote:
> Is it interested to get the following issues in the release ? Thanks !
>
> HADOOP-1067
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-dev@hadoop.apache.org
Cc: Vinod Kumar Vavilapalli; Hadoop Commo
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,
Agreed. The difference between a 3.0 GA release and a parallel 2.x release line
is just JDK8 + a different classpath (potentially isolated) - doesn't sound
like a big enough delta warranting the license to break compat.
Thanks,
+Vinod
On Mar 2, 2015, at 6:30 PM, Arun Murthy wrote:
> Andrew,
>
> 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 t
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).
L
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
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-...@hadoop.apache.org; mapre
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: common-...@hadoop.apache.
+1
Regards,
Yi Liu
-Original Message-
From: Andrew Wang [mailto:andrew.w...@cloudera.com]
Sent: Tuesday, March 03, 2015 7:20 AM
To: common-...@hadoop.apache.org; mapreduce-...@hadoop.apache.org;
hdfs-dev@hadoop.apache.org; yarn-...@hadoop.apache.org
Subject: Looking to a Hadoop 3 releas
+1 Happy to help too
On Mon, Mar 2, 2015 at 3:57 PM, Yongjun Zhang 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
> wrote:
>
> > Hi devs,
> >
> > It's been a year and a half since 2.x went GA, an
[
https://issues.apache.org/jira/browse/HDFS-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akira AJISAKA resolved HDFS-5518.
-
Resolution: Duplicate
Target Version/s: (was: 3.0.0)
Fixed by HADOOP-11600. Now Hadoop
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.
>
> Regar
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
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
+1. Would love to help.
On Mon, Mar 2, 2015 at 3:19 PM, 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
> have a tremendous positive i
+1
On Mon, Mar 2, 2015 at 3:19 PM, 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
> have a tremendous positive impact for our users.
+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
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
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 been
Jing Zhao created HDFS-7871:
---
Summary: NameNodeEditLogRoller can keep printing "Swallowing
exception" message
Key: HDFS-7871
URL: https://issues.apache.org/jira/browse/HDFS-7871
Project: Hadoop HDFS
[
https://issues.apache.org/jira/browse/HDFS-7837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jing Zhao resolved HDFS-7837.
-
Resolution: Fixed
Fix Version/s: HDFS-7285
Hadoop Flags: Reviewed
Thanks Zhe again for the revi
Thanh Do created HDFS-7870:
--
Summary: remove libuuid dependency
Key: HDFS-7870
URL: https://issues.apache.org/jira/browse/HDFS-7870
Project: Hadoop HDFS
Issue Type: Sub-task
Reporter: Th
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 *exist
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 e
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 pl
J.Andreina created HDFS-7869:
Summary: Inconsistency in the return information while performing
rolling upgrade
Key: HDFS-7869
URL: https://issues.apache.org/jira/browse/HDFS-7869
Project: Hadoop HDFS
zhouyingchao created HDFS-7868:
--
Summary: Use proper blocksize to choose target for blocks
Key: HDFS-7868
URL: https://issues.apache.org/jira/browse/HDFS-7868
Project: Hadoop HDFS
Issue Type: Bu
J.Andreina created HDFS-7867:
Summary: Update action param from "start" to "prepare" in rolling
upgrade code comment.
Key: HDFS-7867
URL: https://issues.apache.org/jira/browse/HDFS-7867
Project: Hadoop HD
Kai Zheng created HDFS-7866:
---
Summary: Erasure coding: Allow NameNode to load, list and sync
predefined EC schemas
Key: HDFS-7866
URL: https://issues.apache.org/jira/browse/HDFS-7866
Project: Hadoop HDFS
33 matches
Mail list logo
