[jira] [Created] (HADOOP-11046) Normalize ACL configuration property across hadoop components

Arun Suresh created HADOOP-11046: Summary: Normalize ACL configuration property across hadoop components Key: HADOOP-11046 URL: https://issues.apache.org/jira/browse/HADOOP-11046 Project: Hadoop

Build failed in Jenkins: Hadoop-Common-0.23-Build #1060

See https://builds.apache.org/job/Hadoop-Common-0.23-Build/1060/ -- [...truncated 8263 lines...] Running org.apache.hadoop.io.file.tfile.TestTFileNoneCodecsJClassComparatorByteArrays Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.489

migrating private branches to the new git repo

Now that hadoop is using git, I'm migrating my various work-in-progress branches to the new commit tree 1. This is the process I've written up for using git format-patch then git am to export the patch sequence and merge it in, then rebasing onto trunk to finally get in sync

Re: migrating private branches to the new git repo

This is basically what I did, make patches of each of my branches and then reapply to the new trunk. One small recommendation would be to make the remote named apache rather than asflive so it's consistent with the GitAndHadoop wikipage. IMO naming branches with a / (e.g. live/trunk) is also kind

[jira] [Created] (HADOOP-11047) tomcat.download.url is mostly ignored by kms

Allen Wittenauer created HADOOP-11047: - Summary: tomcat.download.url is mostly ignored by kms Key: HADOOP-11047 URL: https://issues.apache.org/jira/browse/HADOOP-11047 Project: Hadoop Common

[jira] [Resolved] (HADOOP-11047) tomcat.download.url is mostly ignored by kms

[ https://issues.apache.org/jira/browse/HADOOP-11047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HADOOP-11047. --- Resolution: Not a Problem Looks like it was always this way, but because I was

Re: migrating private branches to the new git repo

On 2 September 2014 19:01, Andrew Wang andrew.w...@cloudera.com wrote: This is basically what I did, make patches of each of my branches and then reapply to the new trunk. One small recommendation would be to make the remote named apache rather than asflive so it's consistent with the

Re: migrating private branches to the new git repo

I've now done my first commits; one into trunk (10373), one into branch-2 and cherry picked (fix in hadoop-common-project/hadoop-common/src/main/native/README ; no JIRA). I made an initial attempt to cherry pick the HADOOP-10373 patch from trunk into branch-2, with CHANGES.TXT being a dramatic

[jira] [Created] (HADOOP-11048) user/custom LogManager fails to load if the client classloader is enabled

Sangjin Lee created HADOOP-11048: Summary: user/custom LogManager fails to load if the client classloader is enabled Key: HADOOP-11048 URL: https://issues.apache.org/jira/browse/HADOOP-11048 Project:

[jira] [Created] (HADOOP-11049) javax package system class default is too broad

Sangjin Lee created HADOOP-11049: Summary: javax package system class default is too broad Key: HADOOP-11049 URL: https://issues.apache.org/jira/browse/HADOOP-11049 Project: Hadoop Common

[jira] [Created] (HADOOP-11050) hconf.c: fix bug where we would sometimes not try to load multiple XML files from the same path

Colin Patrick McCabe created HADOOP-11050: - Summary: hconf.c: fix bug where we would sometimes not try to load multiple XML files from the same path Key: HADOOP-11050 URL:

[jira] [Created] (HADOOP-11051) implement ndfs_get_hosts

Colin Patrick McCabe created HADOOP-11051: - Summary: implement ndfs_get_hosts Key: HADOOP-11051 URL: https://issues.apache.org/jira/browse/HADOOP-11051 Project: Hadoop Common Issue

Re: migrating private branches to the new git repo

Maybe at the end add the action I will ultimately take (git branch remote rename asflive origin git branch rename live/trunk trunk) +1, that'd be great Somewhat related, it'd be nice to update the GitAndHadoop instructions on how to generate a patch using git-format-patch. I've been

Re: migrating private branches to the new git repo

Not to derail the conversation, but if CHANGES.txt is making backports more annoying, why don't we get rid of it? It seems like we should be able to generate it via a JIRA query, and git log can also be used for a quick check (way faster than svn log). On Tue, Sep 2, 2014 at 12:38 PM, Steve

[jira] [Created] (HADOOP-11053) Depends on EOL commons-httpclient

Steven Noble created HADOOP-11053: - Summary: Depends on EOL commons-httpclient Key: HADOOP-11053 URL: https://issues.apache.org/jira/browse/HADOOP-11053 Project: Hadoop Common Issue Type:

[jira] [Created] (HADOOP-11054) Add a KeyProvider instantiation based on a URI

Alejandro Abdelnur created HADOOP-11054: --- Summary: Add a KeyProvider instantiation based on a URI Key: HADOOP-11054 URL: https://issues.apache.org/jira/browse/HADOOP-11054 Project: Hadoop Common

[jira] [Created] (HADOOP-11055) non-daemon pid files are missing

Allen Wittenauer created HADOOP-11055: - Summary: non-daemon pid files are missing Key: HADOOP-11055 URL: https://issues.apache.org/jira/browse/HADOOP-11055 Project: Hadoop Common Issue

Re: migrating private branches to the new git repo

On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang andrew.w...@cloudera.com wrote: Not to derail the conversation, but if CHANGES.txt is making backports more annoying, why don't we get rid of it? It seems like we should be able to generate it via a JIRA query, and git log can also be used for a