[
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.
{quot
On Mar 18, 2015, at 2:32 PM, Andrew Wang 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 that actually have releas
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
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
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
I don't think we should try and build CHANGES.txt out of git log output.
There are a number of issues:
- We've all fatfingered JIRA #s when writing the commit message, leading to
false positives
- If something is committed then reverted, it's a false positive
- Both of the above are a consequence
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
into
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 Hado
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
Proje
[
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.
Hi Ewan,
Sure, I'll check it.
Thanks,
- Tsuyoshi
On Wed, Mar 18, 2015 at 7:29 PM, Ewan Higgs 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? I've tested it on G
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 it.
14 matches
Mail list logo
