[jira] [Created] (HDFS-9654) Code refactoring for HDFS-8578

2016-01-16 Thread Tsz Wo Nicholas Sze (JIRA)
Tsz Wo Nicholas Sze created HDFS-9654: - Summary: Code refactoring for HDFS-8578 Key: HDFS-9654 URL: https://issues.apache.org/jira/browse/HDFS-9654 Project: Hadoop HDFS Issue Type: Improv

[jira] [Created] (HDFS-9655) NN should start JVM pause monitor before loading fsimage

2016-01-16 Thread John Zhuge (JIRA)
John Zhuge created HDFS-9655: Summary: NN should start JVM pause monitor before loading fsimage Key: HDFS-9655 URL: https://issues.apache.org/jira/browse/HDFS-9655 Project: Hadoop HDFS Issue Type

Re: [VOTE] Release Apache Hadoop 2.7.2 RC2

2016-01-16 Thread Akira AJISAKA
Hi Xiao, > From a quick comparison between the releasenotes.html and the CHANGES.txt > files in source tarball, the number of total JIRAs is quite different. In CHANGES.txt, JIRAs fixed in 2.6.1/2.6.2 are not in 2.7.2. That is why the number of JIRAs are different. Regards, Akira On 1/16/16

Build failed in Jenkins: Hadoop-Hdfs-trunk-Java8 #799

2016-01-16 Thread Apache Jenkins Server
See Changes: [szetszwo] In CHANGES.txt, move HDFS-9294 to Release 2.6.4. [cnauroth] HADOOP-12691. Move files to correct location. -- [...truncated 5767 lines...] Tests run: 2, Failures: 0

Hadoop-Hdfs-trunk-Java8 - Build # 799 - Still Failing

2016-01-16 Thread Apache Jenkins Server
See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/799/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 5960 lines...] [INFO] --- maven-antrun-plugin:1.7:ru

Jenkins build is back to normal : Hadoop-Hdfs-trunk #2736

2016-01-16 Thread Apache Jenkins Server
See

Re: [VOTE] Release Apache Hadoop 2.7.2 RC2

2016-01-16 Thread Xiao Chen
Got it, makes sense. Thanks Akira for answering! -Xiao On Sat, Jan 16, 2016 at 11:39 AM, Akira AJISAKA wrote: > Hi Xiao, > > > From a quick comparison between the releasenotes.html and the > CHANGES.txt > > files in source tarball, the number of total JIRAs is quite different. > > In CHANGES.t

Re: [VOTE] Release Apache Hadoop 2.7.2 RC2

2016-01-16 Thread Junping Du
In addition, all new fixes backport from 2.6.3 doesn't listed in 2.7.2 entry of CHANGES.txt but keep listed as 2.6.3. I think this is fine no matter we have multiple entries to track the same commit or a single entry to track the earliest commit. The only thing matter is the commits in release n