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

See -- [...truncated 8263 lines...] Running org.apache.hadoop.io.file.tfile.TestTFileNoneCodecsJClassComparatorByteArrays Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.536 s

Re: migrating private branches to the new git repo

On 3 September 2014 02:47, Todd Lipcon wrote: > On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang > 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,

[jira] [Created] (HADOOP-11056) OsSecureRandom.setConf() might leak resource

Yongjun Zhang created HADOOP-11056: -- Summary: OsSecureRandom.setConf() might leak resource Key: HADOOP-11056 URL: https://issues.apache.org/jira/browse/HADOOP-11056 Project: Hadoop Common Is

[jira] [Created] (HADOOP-11057) checknative command to probe for winutils.exe on windows

Steve Loughran created HADOOP-11057: --- Summary: checknative command to probe for winutils.exe on windows Key: HADOOP-11057 URL: https://issues.apache.org/jira/browse/HADOOP-11057 Project: Hadoop Commo

[jira] [Created] (HADOOP-11058) Missing HADOOP_CONF_DIR generates strange results

Allen Wittenauer created HADOOP-11058: - Summary: Missing HADOOP_CONF_DIR generates strange results Key: HADOOP-11058 URL: https://issues.apache.org/jira/browse/HADOOP-11058 Project: Hadoop Common

Re: migrating private branches to the new git repo

On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang 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 quick > check (way faster

[jira] [Created] (HADOOP-11059) relnotes.py should figure out the previous version by itself

Karthik Kambatla created HADOOP-11059: - Summary: relnotes.py should figure out the previous version by itself Key: HADOOP-11059 URL: https://issues.apache.org/jira/browse/HADOOP-11059 Project: Had

Re: migrating private branches to the new git repo

On Sep 3, 2014, at 11:07 AM, Chris Douglas wrote: > > As long as release notes and incompatible changes are recorded in each > branch, we gain no accuracy by maintaining this manually. Commit > messages that record the merge revisions instead of the change are > similarly hateful. -C We’ll als

Re: migrating private branches to the new git repo

On Sep 3, 2014, at 11:42 AM, Allen Wittenauer wrote: > > On Sep 3, 2014, at 11:07 AM, Chris Douglas wrote: > >> >> As long as release notes and incompatible changes are recorded in each >> branch, we gain no accuracy by maintaining this manually. Commit >> messages that record the merge revi

Re: migrating private branches to the new git repo

Allen, if you're willing to do the legwork, that'd be great. I feel we should start by getting a JIRA script checked into dev-support that generates a changelog for a release. We could then use that to make sure the various fields are set properly for previous releases, remove CHANGES.txt once we'r

Re: migrating private branches to the new git repo

Looks like the web UI doesn't allow for bulk change of Fix Version. *cries* On Sep 3, 2014, at 11:56 AM, Andrew Wang wrote: > Allen, if you're willing to do the legwork, that'd be great. I feel we > should start by getting a JIRA script checked into dev-support that > generates a changelog fo

Re: migrating private branches to the new git repo

OK, it does, but only under certain conditions. Hmm. On Sep 3, 2014, at 12:04 PM, Allen Wittenauer wrote: > > > Looks like the web UI doesn't allow for bulk change of Fix Version. > > *cries* > > On Sep 3, 2014, at 11:56 AM, Andrew Wang wrote: > >> Allen, if you're willing to do the legwo

[jira] [Resolved] (HADOOP-10931) compile error on project "Apache Hadoop OpenStack support"

[ https://issues.apache.org/jira/browse/HADOOP-10931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Wittenauer resolved HADOOP-10931. --- Resolution: Fixed > compile error on project "Apache Hadoop OpenStack support" > ---

Re: migrating private branches to the new git repo

Figured it out. Basically can only do bulk fix version edits of one project at a time since the versions are technically different for every project. i.e.,: you can edit all of YARN-xxx, but you can not do YARN-xxx and HDFS-xxx together. FWIW, there are 372 issues that have a fixVersion for

Re: migrating private branches to the new git repo

Allen, I think the correct field you are looking for is 'Target Version'. If a fix is committed to both branch-2 and trunk, the fix version must include both 2.x.0 and 3.0.0. However the target version would be 2.x.0 as that is the earliest release that includes the fix. On Wed, Sep 3, 2014 at 12

[jira] [Created] (HADOOP-11060) Create a CryptoCodec test that verifies interoperability between the JCE and OpenSSL implementations

Alejandro Abdelnur created HADOOP-11060: --- Summary: Create a CryptoCodec test that verifies interoperability between the JCE and OpenSSL implementations Key: HADOOP-11060 URL: https://issues.apache.org/jira/b

Re: migrating private branches to the new git repo

I was doing that too, but I went "to the source": https://wiki.apache.org/hadoop/HowToCommit says: "Resolve the issue as fixed, thanking the contributor. Always set the "Fix Version" at this point, but please only set a single fix version, the earliest release in which the change will appear. S

Re: migrating private branches to the new git repo

Thanks, good to know. So in the spirit of simplification can we just eliminate the 'Target Version' field from Jira? On Wed, Sep 3, 2014 at 1:01 PM, Allen Wittenauer wrote: > I was doing that too, but I went "to the source": > > https://wiki.apache.org/hadoop/HowToCommit says: > > "Resolve the

Re: migrating private branches to the new git repo

I always used target version as "I hope to get this patch in by then". :D On Sep 3, 2014, at 1:07 PM, Arpit Agarwal wrote: > Thanks, good to know. > > So in the spirit of simplification can we just eliminate the 'Target > Version' field from Jira? > > > On Wed, Sep 3, 2014 at 1:01 PM, Allen

[DISCUSS] Hadoop 2.5.1

Hi folks Now that all issues with target 2.5.1 are committed, I am planning to cut an RC for 2.5.1 this Friday. The fixes going into 2.5.1 are - http://s.apache.org/2Mz Are there any other "Blocker" issues that we would like to get into 2.5.1? If there are any, please mark them as "Blocker" and t

Re: migrating private branches to the new git repo

Not sure it is sufficient reason to keep the field around given the confusion it causes. :-) Thanks for volunteering to cleanup the existing Jiras. On Wed, Sep 3, 2014 at 1:09 PM, Allen Wittenauer wrote: > > I always used target version as "I hope to get this patch in by then". :D > > > On Sep

Re: migrating private branches to the new git repo

On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang 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 quick > check (way faste

Re: migrating private branches to the new git repo

I personally find Target Version to be useful for tracking which version a change is intended for. On Wed, Sep 3, 2014 at 2:55 PM, Karthik Kambatla wrote: > On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang > wrote: > > > Not to derail the conversation, but if CHANGES.txt is making backports > more

Re: migrating private branches to the new git repo

On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer wrote: > We’ll also need to get much more strict about Fix Version really only listing > the earliest version. Many of list (next release) + (trunk), myself > included, which after looking through some of the commit docs, is not correct. Is thi

Re: migrating private branches to the new git repo

Sorry, if I wasn't clear. I find Target and Fix versions useful. I find CHANGES.txt redundant. On Wed, Sep 3, 2014 at 2:55 PM, Karthik Kambatla wrote: > > On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang > wrote: > >> Not to derail the conversation, but if CHANGES.txt is making backports >> more >>

Re: migrating private branches to the new git repo

On Sep 3, 2014, at 4:57 PM, Chris Douglas wrote: > On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer wrote: >> We’ll also need to get much more strict about Fix Version really only >> listing the earliest version. Many of list (next release) + (trunk), myself >> included, which after looki

auto-generating changes.txt was: migrating private branches to the new git repo

Nothing official or clean or whatever, but just to give people an idea of what an auto generated CHANGES.txt file might look like, here are some sample runs of the hacky thing I built, based upon the fixVersion information. It doesn't break it down by improvement, etc. Also, the name on the en

Re: auto-generating changes.txt was: migrating private branches to the new git repo

2.5.1 - I believe all the commits here are in CHANGES.txt of 2.5.1. Which one is missing? On Wed, Sep 3, 2014 at 6:51 PM, Allen Wittenauer wrote: > Nothing official or clean or whatever, but just to give people an idea of > what an auto generated CHANGES.txt file might look like, here are some

Re: auto-generating changes.txt was: migrating private branches to the new git repo

I don't see HADOOP-10957 in hadoop-common-project/hadoop-cmmon/CHANGES.txt on github in the 2.5.1 branch. On Sep 3, 2014, at 7:00 PM, Karthik Kambatla wrote: > 2.5.1 - I believe all the commits here are in CHANGES.txt of 2.5.1. Which > one is missing? > > > On Wed, Sep 3, 2014 at 6:51 PM, Al

Re: auto-generating changes.txt was: migrating private branches to the new git repo

Oh, it's in hdfs. Sneaky. On Sep 3, 2014, at 7:10 PM, Allen Wittenauer wrote: > > I don't see HADOOP-10957 in hadoop-common-project/hadoop-cmmon/CHANGES.txt on > github in the 2.5.1 branch. > > On Sep 3, 2014, at 7:00 PM, Karthik Kambatla wrote: > >> 2.5.1 - I believe all the commits here

Re: Git repo ready to use

It seems like the github mirror at https://github.com/apache/hadoop-common has stopped getting updates as of 8/22. Could this mirror have been broken by the git transition? Thanks, Sangjin On Fri, Aug 29, 2014 at 11:51 AM, Ted Yu wrote: > From https://builds.apache.org/job/Hadoop-hdfs-trunk/18

Re: Git repo ready to use

I think its still pointing to old svn repository which is just read only now. You can use latest mirror: https://github.com/apache/hadoop Regards, Vinay On Sep 4, 2014 11:37 AM, "Sangjin Lee" wrote: > It seems like the github mirror at https://github.com/apache/hadoop-common > has stopped getti