Re: Does VOTE necessary to create a child repo?

[Vinod Kumar Vavilapalli]

Moving the thread to the dev lists.

Thanks
+Vinod

> On Sep 23, 2019, at 11:43 PM, Vinayakumar B  wrote:
> 
> Thanks Marton,
> 
> Current created 'hadoop-thirdparty' repo is empty right now.
> Whether to use that repo  for shaded artifact or not will be monitored in
> HADOOP-13363 umbrella jira. Please feel free to join the discussion.
> 
> There is no existing codebase is being moved out of hadoop repo. So I think
> right now we are good to go.
> 
> -Vinay
> 
> On Mon, Sep 23, 2019 at 11:38 PM Marton Elek  wrote:
> 
>> 
>> I am not sure if it's defined when is a vote required.
>> 
>> https://www.apache.org/foundation/voting.html
>> 
>> Personally I think it's a big enough change to send a notification to the
>> dev lists with a 'lazy consensus'  closure
>> 
>> Marton
>> 
>> On 2019/09/23 17:46:37, Vinayakumar B  wrote:
>>> Hi,
>>> 
>>> As discussed in HADOOP-13363, protobuf 3.x jar (and may be more in
>> future)
>>> will be kept as a shaded artifact in a separate repo, which will be
>>> referred as dependency in hadoop modules.  This approach avoids shading
>> of
>>> every submodule during build.
>>> 
>>> So question is does any VOTE required before asking to create a git repo?
>>> 
>>> On selfserve platform https://gitbox.apache.org/setup/newrepo.html
>>> I can access see that, requester should be PMC.
>>> 
>>> Wanted to confirm here first.
>>> 
>>> -Vinay
>>> 
>> 
>> -
>> To unsubscribe, e-mail: private-unsubscr...@hadoop.apache.org
>> For additional commands, e-mail: private-h...@hadoop.apache.org
>> 
>> 


-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[GitHub] [hadoop-thirdparty] vinayakumarb opened a new pull request #1: HADOOP-16595. [pb-upgrade] Create hadoop-thirdparty artifact to have shaded protobuf

[GitBox]

vinayakumarb opened a new pull request #1: HADOOP-16595. [pb-upgrade] Create 
hadoop-thirdparty artifact to have shaded protobuf
URL: https://github.com/apache/hadoop-thirdparty/pull/1
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[DISCUSS] Release Docs pointers Hadoop site

[Sunil Govindan]

Hi Folks,

At present,
http://hadoop.apache.org/docs/stable/  points to *Apache Hadoop 3.2.1*
http://hadoop.apache.org/docs/current/ points to *Apache Hadoop 3.2.1*
http://hadoop.apache.org/docs/stable2/  points to *Apache Hadoop 2.9.2*
http://hadoop.apache.org/docs/current2/ points to *Apache Hadoop 2.9.2*

3.2.1 is released last day. *Now 3.1.3 has completed voting* and it is in
the final stages of staging
As per me,
a) 3.2.1 will be still be pointing to http://hadoop.apache.org/docs/stable/
?
b) 3.1.3 should be pointing to http://hadoop.apache.org/docs/current/ ?

Now my questions,
1. But if the release manager of 3.1 line thinks 3.1.3 is stable, and 3.2
line is also in stable state, which release should get precedence to be
called as *stable* in any release line (2.x or 3.x) ?
or do we need a vote or discuss thread to decide which release shall be
called as stable per release line?
2. Given 3.2.1 is released and pointing to 3.2.1 as stable, then when 3.1.3
is getting released now, could http://hadoop.apache.org/docs/current/ shall
be updated to 3.1.3 ? is it the norms ?

Thanks
Sunil

Re: Release plans for Hadoop 2.10.0

[Viral Bajaria]

Hi Wei-Chiu,

I came across HDFS-14476 when searching if anyone else is seeing the same
issues as us. I didn't see it merged and so assumed there are other fixes
done around what you mention in there.

HDFS-11187 is already applied to 2.9.1 and we are on 2.9.2 and so it might
not be impacting us though I need to be 100% sure of it.

I will find the jstack as soon as I am on the server again, but I have the
following WARN statement that I felt could point to the issue. Btw, we have
tested the disk I/O and when these slowdown happen the disk is hardly under
any kind of I/O pressure. And on restart of the datanode process all goes
back to normal i.e. the disks are able to do high I/O.

2019-09-27 00:48:14,101 WARN
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetImpl:
Lock held time above threshold: lock identifier:
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsD
atasetImpl lockHeldTimeMs=12628 ms. Suppressed 1 lock warnings. The
stack trace is: java.lang.Thread.getStackTrace(Thread.java:1559)
org.apache.hadoop.util.StringUtils.getStackTrace(StringUtils.java:1021)
org.apache.hadoop.util.InstrumentedLock.logWarning(InstrumentedLock.java:143)
org.apache.hadoop.util.InstrumentedLock.check(InstrumentedLock.java:186)
org.apache.hadoop.util.InstrumentedLock.unlock(InstrumentedLock.java:133)
org.apache.hadoop.util.AutoCloseableLock.release(AutoCloseableLock.java:84)
org.apache.hadoop.util.AutoCloseableLock.close(AutoCloseableLock.java:96)
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetImpl.finalizeBlock(FsDatasetImpl.java:1781)
org.apache.hadoop.hdfs.server.datanode.BlockReceiver$PacketResponder.finalizeBlock(BlockReceiver.java:1517)
org.apache.hadoop.hdfs.server.datanode.BlockReceiver$PacketResponder.run(BlockReceiver.java:1474)
java.lang.Thread.run(Thread.java:748)


Thanks,
Viral






On Thu, Sep 26, 2019 at 7:03 PM Wei-Chiu Chuang 
wrote:

> or maybe https://issues.apache.org/jira/browse/HDFS-14476
>
> I reverted this fix and I've not looked at it further. But take a look.
> It's disappointing to me that none of the active Hadoop contributors seem
> to understand DirectoryScanner well enough.
>
> or HDFS-11187 
>
> If you can post a jstack snippet I might be able to help out.
> On Thu, Sep 26, 2019 at 9:48 PM Viral Bajaria 
> wrote:
>
>> Thanks for the quick response Jonathan.
>>
>> Honestly, I am not sure if 2.10.0 will fix my issue but it looks similar
>> to
>> https://issues.apache.org/jira/browse/HDFS-14536 which is not fixed yet
>> so
>> we will probably not see the benefit.
>>
>> We need to either dig more into the logs and jstack and create a JIRA to
>> see if the developers can comment on what's going on. A datanode restart
>> fixes the latency issue and so it is something that happens over time and
>> need the right instrumentation to figure it out!
>>
>> Thanks,
>> Viral
>>
>>
>> On Thu, Sep 26, 2019 at 6:41 PM Jonathan Hung 
>> wrote:
>>
>> > Hey Viral, yes. We're working on a 2.10.0 release, I'm the release
>> manager
>> > for that. I can't comment on the particular issue you're seeing, but I
>> plan
>> > to start the release process for 2.10.0 early next week, then 2.10.0
>> will
>> > be released shortly after that (assuming all goes well).
>> >
>> > Thanks,
>> > Jonathan Hung
>> >
>> >
>> > On Thu, Sep 26, 2019 at 6:34 PM Viral Bajaria 
>> > wrote:
>> >
>> >> (Cross posting from user list based on feedback by Sean Busbey)
>> >>
>> >> All,
>> >>
>> >> Just saw the announcement for new release for Hadoop 3.2.1,
>> >> congratulations
>> >> team and thanks for all the hard work!
>> >>
>> >> Are we going to see a new release in the 2.x.x ?
>> >>
>> >> I noticed a bunch of tickets that have been resolved in the last year
>> have
>> >> been tagged with 2.10.0 as a fix version and it's been a while since
>> 2.9.2
>> >> was released so I was wondering if we are going to see a 2.10.0 release
>> >> soon OR should we start looking to upgarde to 3.x line ?
>> >>
>> >> The reason I ask is that we are seeing very high ReadBlockOp Latency on
>> >> our
>> >> datanodes and feel that the issue is due to some locking going on
>> between
>> >> VolumeScanner, DirectoryScanner, RW Block Operations and
>> MetricsRegistry.
>> >> Looking at a few JIRA it looks like 2.10.0 might have some fixes that
>> we
>> >> should try, not fully sure yet!
>> >>
>> >> Thanks,
>> >> Viral
>> >>
>> >
>>
>

[jira] [Created] (HADOOP-16612) Track Azure Blob File System client-perceived latency

[Jeetesh Mangwani (Jira)]

Jeetesh Mangwani created HADOOP-16612:
-

 Summary: Track Azure Blob File System client-perceived latency
 Key: HADOOP-16612
 URL: https://issues.apache.org/jira/browse/HADOOP-16612
 Project: Hadoop Common
  Issue Type: Sub-task
  Components: fs/azure, hdfs-client
Reporter: Jeetesh Mangwani


Track the performance of Hadoop ABFS driver by measuring the latencies of ADLS 
Gen 2 REST APIs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Re: Release plans for Hadoop 2.10.0

[Wei-Chiu Chuang]

or maybe https://issues.apache.org/jira/browse/HDFS-14476

I reverted this fix and I've not looked at it further. But take a look.
It's disappointing to me that none of the active Hadoop contributors seem
to understand DirectoryScanner well enough.

or HDFS-11187 

If you can post a jstack snippet I might be able to help out.
On Thu, Sep 26, 2019 at 9:48 PM Viral Bajaria 
wrote:

> Thanks for the quick response Jonathan.
>
> Honestly, I am not sure if 2.10.0 will fix my issue but it looks similar to
> https://issues.apache.org/jira/browse/HDFS-14536 which is not fixed yet so
> we will probably not see the benefit.
>
> We need to either dig more into the logs and jstack and create a JIRA to
> see if the developers can comment on what's going on. A datanode restart
> fixes the latency issue and so it is something that happens over time and
> need the right instrumentation to figure it out!
>
> Thanks,
> Viral
>
>
> On Thu, Sep 26, 2019 at 6:41 PM Jonathan Hung 
> wrote:
>
> > Hey Viral, yes. We're working on a 2.10.0 release, I'm the release
> manager
> > for that. I can't comment on the particular issue you're seeing, but I
> plan
> > to start the release process for 2.10.0 early next week, then 2.10.0 will
> > be released shortly after that (assuming all goes well).
> >
> > Thanks,
> > Jonathan Hung
> >
> >
> > On Thu, Sep 26, 2019 at 6:34 PM Viral Bajaria 
> > wrote:
> >
> >> (Cross posting from user list based on feedback by Sean Busbey)
> >>
> >> All,
> >>
> >> Just saw the announcement for new release for Hadoop 3.2.1,
> >> congratulations
> >> team and thanks for all the hard work!
> >>
> >> Are we going to see a new release in the 2.x.x ?
> >>
> >> I noticed a bunch of tickets that have been resolved in the last year
> have
> >> been tagged with 2.10.0 as a fix version and it's been a while since
> 2.9.2
> >> was released so I was wondering if we are going to see a 2.10.0 release
> >> soon OR should we start looking to upgarde to 3.x line ?
> >>
> >> The reason I ask is that we are seeing very high ReadBlockOp Latency on
> >> our
> >> datanodes and feel that the issue is due to some locking going on
> between
> >> VolumeScanner, DirectoryScanner, RW Block Operations and
> MetricsRegistry.
> >> Looking at a few JIRA it looks like 2.10.0 might have some fixes that we
> >> should try, not fully sure yet!
> >>
> >> Thanks,
> >> Viral
> >>
> >
>

Re: Release plans for Hadoop 2.10.0

[Viral Bajaria]

Thanks for the quick response Jonathan.

Honestly, I am not sure if 2.10.0 will fix my issue but it looks similar to
https://issues.apache.org/jira/browse/HDFS-14536 which is not fixed yet so
we will probably not see the benefit.

We need to either dig more into the logs and jstack and create a JIRA to
see if the developers can comment on what's going on. A datanode restart
fixes the latency issue and so it is something that happens over time and
need the right instrumentation to figure it out!

Thanks,
Viral


On Thu, Sep 26, 2019 at 6:41 PM Jonathan Hung  wrote:

> Hey Viral, yes. We're working on a 2.10.0 release, I'm the release manager
> for that. I can't comment on the particular issue you're seeing, but I plan
> to start the release process for 2.10.0 early next week, then 2.10.0 will
> be released shortly after that (assuming all goes well).
>
> Thanks,
> Jonathan Hung
>
>
> On Thu, Sep 26, 2019 at 6:34 PM Viral Bajaria 
> wrote:
>
>> (Cross posting from user list based on feedback by Sean Busbey)
>>
>> All,
>>
>> Just saw the announcement for new release for Hadoop 3.2.1,
>> congratulations
>> team and thanks for all the hard work!
>>
>> Are we going to see a new release in the 2.x.x ?
>>
>> I noticed a bunch of tickets that have been resolved in the last year have
>> been tagged with 2.10.0 as a fix version and it's been a while since 2.9.2
>> was released so I was wondering if we are going to see a 2.10.0 release
>> soon OR should we start looking to upgarde to 3.x line ?
>>
>> The reason I ask is that we are seeing very high ReadBlockOp Latency on
>> our
>> datanodes and feel that the issue is due to some locking going on between
>> VolumeScanner, DirectoryScanner, RW Block Operations and MetricsRegistry.
>> Looking at a few JIRA it looks like 2.10.0 might have some fixes that we
>> should try, not fully sure yet!
>>
>> Thanks,
>> Viral
>>
>

Re: Release plans for Hadoop 2.10.0

[Jonathan Hung]

Hey Viral, yes. We're working on a 2.10.0 release, I'm the release manager
for that. I can't comment on the particular issue you're seeing, but I plan
to start the release process for 2.10.0 early next week, then 2.10.0 will
be released shortly after that (assuming all goes well).

Thanks,
Jonathan Hung


On Thu, Sep 26, 2019 at 6:34 PM Viral Bajaria 
wrote:

> (Cross posting from user list based on feedback by Sean Busbey)
>
> All,
>
> Just saw the announcement for new release for Hadoop 3.2.1, congratulations
> team and thanks for all the hard work!
>
> Are we going to see a new release in the 2.x.x ?
>
> I noticed a bunch of tickets that have been resolved in the last year have
> been tagged with 2.10.0 as a fix version and it's been a while since 2.9.2
> was released so I was wondering if we are going to see a 2.10.0 release
> soon OR should we start looking to upgarde to 3.x line ?
>
> The reason I ask is that we are seeing very high ReadBlockOp Latency on our
> datanodes and feel that the issue is due to some locking going on between
> VolumeScanner, DirectoryScanner, RW Block Operations and MetricsRegistry.
> Looking at a few JIRA it looks like 2.10.0 might have some fixes that we
> should try, not fully sure yet!
>
> Thanks,
> Viral
>

Release plans for Hadoop 2.10.0

[Viral Bajaria]

(Cross posting from user list based on feedback by Sean Busbey)

All,

Just saw the announcement for new release for Hadoop 3.2.1, congratulations
team and thanks for all the hard work!

Are we going to see a new release in the 2.x.x ?

I noticed a bunch of tickets that have been resolved in the last year have
been tagged with 2.10.0 as a fix version and it's been a while since 2.9.2
was released so I was wondering if we are going to see a 2.10.0 release
soon OR should we start looking to upgarde to 3.x line ?

The reason I ask is that we are seeing very high ReadBlockOp Latency on our
datanodes and feel that the issue is due to some locking going on between
VolumeScanner, DirectoryScanner, RW Block Operations and MetricsRegistry.
Looking at a few JIRA it looks like 2.10.0 might have some fixes that we
should try, not fully sure yet!

Thanks,
Viral

[jira] [Resolved] (HADOOP-16489) S3Guard operations log has tombstone/PUT swapped

[Steve Loughran (Jira)]

 [ 
https://issues.apache.org/jira/browse/HADOOP-16489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran resolved HADOOP-16489.
-
Fix Version/s: 3.3.0
   Resolution: Duplicate

fixed this in HADOOP-16430

> S3Guard operations log has tombstone/PUT swapped
> 
>
> Key: HADOOP-16489
> URL: https://issues.apache.org/jira/browse/HADOOP-16489
> Project: Hadoop Common
>  Issue Type: Sub-task
>  Components: fs/s3
>Affects Versions: 3.3.0
>Reporter: Steve Loughran
>Priority: Minor
> Fix For: 3.3.0
>
>
> HADOOP-16384 added a log of ongoing operations, e.g PUT/DELETE/TOMBSTONE; but 
> the put/tombstone values are inverted.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

[jira] [Resolved] (HADOOP-15672) add s3guard CLI command to generate session keys for an assumed role

[Steve Loughran (Jira)]

 [ 
https://issues.apache.org/jira/browse/HADOOP-15672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran resolved HADOOP-15672.
-
Fix Version/s: 3.3.0
   Resolution: Duplicate

> add s3guard CLI command to generate session keys for an assumed role
> 
>
> Key: HADOOP-15672
> URL: https://issues.apache.org/jira/browse/HADOOP-15672
> Project: Hadoop Common
>  Issue Type: Sub-task
>  Components: fs/s3
>Affects Versions: 3.2.0
>Reporter: Steve Loughran
>Priority: Minor
> Fix For: 3.3.0
>
>
> the aws cli 
> [get-session-token|https://docs.aws.amazon.com/cli/latest/reference/sts/get-session-token.html]
>  can generate the keys for short-lived session.
> I'd like something similar in an s3guard command, e.g. "create-role-keys", 
> which would take the existing (full) credentials and optionally: 
>  * ARN of role to adopt
>  * duration
>  * name
>  * restrictions as path to a JSON file or just stdin
>  * output format
>  * whether to use a per-bucket binding for the credentials in the property 
> names generated
>  * MFA secrets
> output formats
> * A JCEKS file (with chosen passwd? For better hive use: append/replace 
> entries in existing file); saved through the hadoop FS APIs to HDFS, file:// 
> or elsewhere
> * hadoop config XML
> * spark properties
> The goal here is to have a workflow where you can generate role credentials 
> to use for a limited time, store them in a JCEKS file and then share them in 
> your jobs. This can be for: Jenkins, Oozie, build files, ..



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org

Apache Hadoop qbt Report: branch2+JDK7 on Linux/x86

[Apache Jenkins Server]

For more details, see 
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/

[Sep 26, 2019 12:50:05 AM] (jhung) Addendum to YARN-9730. Support forcing 
configured partitions to be




-1 overall


The following subsystems voted -1:
asflicense findbugs hadolint pathlen unit xml


The following subsystems voted -1 but
were configured to be filtered/ignored:
cc checkstyle javac javadoc pylint shellcheck shelldocs whitespace


The following subsystems are considered long running:
(runtime bigger than 1h  0m  0s)
unit


Specific tests:

XML :

   Parsing Error(s): 
   
hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/conf/empty-configuration.xml
 
   hadoop-tools/hadoop-azure/src/config/checkstyle-suppressions.xml 
   hadoop-yarn-project/hadoop-yarn/hadoop-yarn-ui/public/crossdomain.xml 
   
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-ui/src/main/webapp/public/crossdomain.xml
 

FindBugs :

   
module:hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-timelineservice-hbase/hadoop-yarn-server-timelineservice-hbase-client
 
   Boxed value is unboxed and then immediately reboxed in 
org.apache.hadoop.yarn.server.timelineservice.storage.common.ColumnRWHelper.readResultsWithTimestamps(Result,
 byte[], byte[], KeyConverter, ValueConverter, boolean) At 
ColumnRWHelper.java:then immediately reboxed in 
org.apache.hadoop.yarn.server.timelineservice.storage.common.ColumnRWHelper.readResultsWithTimestamps(Result,
 byte[], byte[], KeyConverter, ValueConverter, boolean) At 
ColumnRWHelper.java:[line 335] 

Failed junit tests :

   hadoop.util.TestReadWriteDiskValidator 
   hadoop.hdfs.qjournal.server.TestJournalNodeRespectsBindHostKeys 
   hadoop.hdfs.TestMultipleNNPortQOP 
   hadoop.registry.secure.TestSecureLogins 
   hadoop.yarn.server.timelineservice.security.TestTimelineAuthFilterForV2 
   hadoop.yarn.client.api.impl.TestAMRMClient 
  

   cc:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-compile-cc-root-jdk1.7.0_95.txt
  [4.0K]

   javac:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-compile-javac-root-jdk1.7.0_95.txt
  [328K]

   cc:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-compile-cc-root-jdk1.8.0_222.txt
  [4.0K]

   javac:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-compile-javac-root-jdk1.8.0_222.txt
  [308K]

   checkstyle:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-checkstyle-root.txt
  [16M]

   hadolint:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-patch-hadolint.txt
  [4.0K]

   pathlen:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/pathlen.txt
  [12K]

   pylint:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-patch-pylint.txt
  [24K]

   shellcheck:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-patch-shellcheck.txt
  [72K]

   shelldocs:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-patch-shelldocs.txt
  [8.0K]

   whitespace:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/whitespace-eol.txt
  [12M]
   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/whitespace-tabs.txt
  [1.3M]

   xml:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/xml.txt
  [12K]

   findbugs:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/branch-findbugs-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-timelineservice-hbase_hadoop-yarn-server-timelineservice-hbase-client-warnings.html
  [8.0K]

   javadoc:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-javadoc-javadoc-root-jdk1.7.0_95.txt
  [16K]
   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/diff-javadoc-javadoc-root-jdk1.8.0_222.txt
  [1.1M]

   unit:

   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/patch-unit-hadoop-common-project_hadoop-common.txt
  [160K]
   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt
  [232K]
   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-registry.txt
  [12K]
   
https://builds.apache.org/job/hadoop-qbt-branch2-java7-linux-x86/456/artifact/out/patch-unit-hadoop-yarn-project_hadoop-yarn_hadoop-yarn-server_hadoop-yarn-server-tests.

[jira] [Resolved] (HADOOP-16611) Make test4tests vote for -0 instead of -1

[Duo Zhang (Jira)]

 [ 
https://issues.apache.org/jira/browse/HADOOP-16611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HADOOP-16611.

Resolution: Not A Problem

> Make test4tests vote for -0 instead of -1
> -
>
> Key: HADOOP-16611
> URL: https://issues.apache.org/jira/browse/HADOOP-16611
> Project: Hadoop Common
>  Issue Type: Sub-task
>  Components: build
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org