See https://builds.apache.org/job/Hadoop-Common-0.23-Build/1061/
--
[...truncated 8263 lines...]
Running
org.apache.hadoop.io.file.tfile.TestTFileNoneCodecsJClassComparatorByteArrays
Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.536
On 3 September 2014 02:47, Todd Lipcon t...@cloudera.com wrote:
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
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
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 quick
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:
On Sep 3, 2014, at 11:07 AM, Chris Douglas cdoug...@apache.org 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
On Sep 3, 2014, at 11:42 AM, Allen Wittenauer a...@altiscale.com wrote:
On Sep 3, 2014, at 11:07 AM, Chris Douglas cdoug...@apache.org wrote:
As long as release notes and incompatible changes are recorded in each
branch, we gain no accuracy by maintaining this manually. Commit
messages
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
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 andrew.w...@cloudera.com 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
OK, it does, but only under certain conditions. Hmm.
On Sep 3, 2014, at 12:04 PM, Allen Wittenauer a...@altiscale.com 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 andrew.w...@cloudera.com wrote:
Allen,
[
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
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
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
Alejandro Abdelnur created HADOOP-11060:
---
Summary: Create a CryptoCodec test that verifies interoperability
between the JCE and OpenSSL implementations
Key: HADOOP-11060
URL:
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.
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 a...@altiscale.com wrote:
I was doing that too, but I went to the source:
https://wiki.apache.org/hadoop/HowToCommit says:
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 aagar...@hortonworks.com 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
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
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 a...@altiscale.com wrote:
I always used target version as I hope to get this patch in by then.
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
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 ka...@cloudera.com wrote:
On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
Not to derail the conversation, but if
On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer a...@altiscale.com 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
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 ka...@cloudera.com wrote:
On Tue, Sep 2, 2014 at 2:38 PM, Andrew Wang andrew.w...@cloudera.com
wrote:
Not to derail the conversation, but if
On Sep 3, 2014, at 4:57 PM, Chris Douglas cdoug...@apache.org wrote:
On Wed, Sep 3, 2014 at 11:42 AM, Allen Wittenauer a...@altiscale.com 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),
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
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 a...@altiscale.com wrote:
Nothing official or clean or whatever, but just to give people an idea of
what an auto generated CHANGES.txt file might look
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 ka...@cloudera.com 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
Oh, it's in hdfs. Sneaky.
On Sep 3, 2014, at 7:10 PM, Allen Wittenauer a...@altiscale.com 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 ka...@cloudera.com wrote:
2.5.1 - I
28 matches
Mail list logo
