Hi Ewan,
Sure, I'll check it.
Thanks,
- Tsuyoshi
On Wed, Mar 18, 2015 at 7:29 PM, Ewan Higgs ewan.hi...@ugent.be wrote:
Hi all,
MAPREDUCE-5528 has been open for about 18 months - the whole time with a
working patch. Can someone please [take a look and verify it themselves and]
merge it?
Hi all,
MAPREDUCE-5528 has been open for about 18 months - the whole time with a
working patch. Can someone please [take a look and verify it themselves
and] merge it? I've tested it on GPFS and it worked for me. If you need
me to mail a PR to a particular address, let me know and I'll send
[
https://issues.apache.org/jira/browse/HADOOP-11721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kihwal Lee resolved HADOOP-11721.
-
Resolution: Fixed
switch jenkins patch tester to use git clean instead of mvn clean
If you want to write the code, knock yourself out. It’ll be interesting to see
what sits in trunk[1]. There is no question that the git log is more accurate,
but collating the information to convey the same message that even our current
changes.txt file is fraught with danger and complexity.
Li Lu created HADOOP-11728:
--
Summary: Try merging USER_FACING_URLS and ALL_URLS
Key: HADOOP-11728
URL: https://issues.apache.org/jira/browse/HADOOP-11728
Project: Hadoop Common
Issue Type: Bug
On Mar 18, 2015, at 2:32 PM, Andrew Wang andrew.w...@cloudera.com wrote:
The bigger question for me is why we have CHANGES.txt at all when we have
release notes, since the information is almost identical.
Yeah, I don’t think it was always like that. Stripping it down to just the
ones
[
https://issues.apache.org/jira/browse/HADOOP-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Takenori Sato reopened HADOOP-10037:
I confirmed this happens on Hadoop 2.6.0, and found the reason.
Here's the stacktrace.
Alan, can you forward those private conversations (or some excerpt
thereof) to the list to explain the problem that you see?
I have been using git log to track change history for years and
never had a problem. In fact, we don't even maintain CHANGES.txt in
Cloudera's distribution including
Haohui Mai created HADOOP-11726:
---
Summary: Allow applications to access both secure and insecure
clusters at the same time
Key: HADOOP-11726
URL: https://issues.apache.org/jira/browse/HADOOP-11726
On the matter of handling merges in the history, this comes up over in
Apache Accumulo where development follows a merge-forward model (commits go
oldest first and merge into newer branches). This means that every commit
on an older-but-still-active development branch eventually ends up merged
Hmm. I'm not sure why something in the history would not be
relevant-- do you mean that the code was removed during the merge?
While that happens sometimes, it doesn't seem that common.
In any case, we have this same problem with CHANGES.txt, JIRA, and
every other issue tracking system we use.
Yitong Zhou created HADOOP-11727:
Summary: Make org.hadoop.util.bloom.BloomFilter returns the
expected false positive probability
Key: HADOOP-11727
URL: https://issues.apache.org/jira/browse/HADOOP-11727
Thanks for that summary, Andrew. In general, I think you're right
that generating it from JIRA would be easier than generating it from
git. We've been pretty good about setting JIRA fix versions.
I do think we could generate it from git if we wanted. We'd have to
have some kind of whitelist or
13 matches
Mail list logo
