[
https://issues.apache.org/jira/browse/HADOOP-8771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andras Bokor resolved HADOOP-8771.
--
Resolution: Won't Fix
CHANGES.txt was removed by HADOOP-11792.
> Correct CHANGES.
Brahma Reddy Battula created HADOOP-14356:
-
Summary: Update CHANGES.txt to reflect all the changes in
branch-2.7
Key: HADOOP-14356
URL: https://issues.apache.org/jira/browse/HADOOP-14356
Brahma Reddy Battula created HADOOP-13670:
-
Summary: Update CHANGES.txt to reflect all the changes in
branch-2.7
Key: HADOOP-13670
URL: https://issues.apache.org/jira/browse/HADOOP-13670
branch-2.7 and branch-2.7.3.
> Update CHANGES.txt to reflect all the changes in branch-2.7
> ---
>
> Key: HADOOP-13312
> URL: https://issues.apache.org/jira/browse/HADOOP-13312
> Proj
Akira AJISAKA created HADOOP-13312:
--
Summary: Update CHANGES.txt to reflect all the changes in
branch-2.7
Key: HADOOP-13312
URL: https://issues.apache.org/jira/browse/HADOOP-13312
Project: Hadoop
w Wang
> wrote:
> > Hi all,
> >
> > With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
> > and release notes are now generated by Yetus. I've gone ahead and deleted
> > the manually updated CHANGES.txt from trunk, branch-2, and branch-2.8
&g
+1
Thanks, Andrew. This will avoid so many spurious conflicts when
cherry-picking changes, and so much wasted time on commit.
best,
Colin
On Thu, Mar 3, 2016 at 9:11 PM, Andrew Wang wrote:
> Hi all,
>
> With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
>
Chris Nauroth created HADOOP-12905:
--
Summary: Clean up CHANGES.txt RAT exclusions from pom.xml files.
Key: HADOOP-12905
URL: https://issues.apache.org/jira/browse/HADOOP-12905
Project: Hadoop Common
gt; With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
> > and release notes are now generated by Yetus. I've gone ahead and deleted
> > the manually updated CHANGES.txt from trunk, branch-2, and branch-2.8
> > (HADOOP-11792). Many thanks to Alle
That's nice, thanks Andrew and Allen.
--Yongjun
On Thu, Mar 3, 2016 at 9:11 PM, Andrew Wang
wrote:
> Hi all,
>
> With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
> and release notes are now generated by Yetus. I've gone ahead and deleted
Hi all,
With the inclusion of HADOOP-12651 going back to branch-2.8, CHANGES.txt
and release notes are now generated by Yetus. I've gone ahead and deleted
the manually updated CHANGES.txt from trunk, branch-2, and branch-2.8
(HADOOP-11792). Many thanks to Allen for the releasedocmaker.py re
away CHANGES.txt on trunk,
branch-2, and branch-2.8. Will send a notice to common-dev, happy committing
all!
> Remove all of the CHANGES.txt files
> ---
>
> Key: HADOOP-11792
> URL: https://issues.apache.org/jira/brow
I'd forgotten about that JIRA (and I'd even commented on it), thanks Akira.
I have branch-2 backports ready for HADOOP-12651, which would swap CHANGES
and release notes generation over to Yetus. Then we can safely delete
CHANGES.txt and not lose any functionality.
Reviews/comments on
I'm fine with deleting CHANGES.txt in branch-2/branch-2.8.
https://issues.apache.org/jira/browse/HADOOP-11792
Thanks,
Akira
On 3/3/16 13:55, Andrew Wang wrote:
I'm more ambivalent about CHANGES.txt these days since it's automatically
generated from JIRA in trunk via the Yetus s
I'm more ambivalent about CHANGES.txt these days since it's automatically
generated from JIRA in trunk via the Yetus script.
It'd be good to do this in branch-2/branch-2.8 too, since then we can stop
editing CHANGES.txt on commit. I'll look into this (again), but more than
h
I'm fine with dropping this step.
I can't help but bring it up again, shouldn't we drop the CHANGES.txt
altogether?
Get Outlook
On Wed, Mar 2, 2016 at 4:16 PM -0800, "Andrew Wang"
wrote:
Hi all,
I wanted to ask a release-related question. Right now, the
Hi all,
I wanted to ask a release-related question. Right now, the RC tarball we
vote on is not the same as the released tarball. This is because one of the
publishing steps is to edit CHANGES.txt to include the release date and
rebuild:
https://wiki.apache.org/hadoop/HowToRelease
I don't
ll be required to get a clean lint run.
The lint tests will evolve as we discover new inconsistencies. Does it
need to be a prerequisite?
We've had this discussion before. Using JIRA is at least as accurate
as CHANGES.txt, we should just use Allen's script (now part of Yetus?)
to gene
x. There are similar issues in other parts
>> of the stack such as YARN.
>>
>> Anyway, as Steve pointed out in his original post, merge conflicts in
>> CHANGES.txt are not the only problem caused by that file. It's simply
>> very inaccurate and misleading, since i
is month's urgent bugfix. There are similar issues in other parts
> of the stack such as YARN.
>
> Anyway, as Steve pointed out in his original post, merge conflicts in
> CHANGES.txt are not the only problem caused by that file. It's simply
> very inaccurate and misleading, si
month's urgent bugfix. There are similar issues in other parts
of the stack such as YARN.
Anyway, as Steve pointed out in his original post, merge conflicts in
CHANGES.txt are not the only problem caused by that file. It's simply
very inaccurate and misleading, since it must be manually
On Sep 14, 2015, at 5:15 PM, Colin P. McCabe wrote:
> Let's stay focused on the title of the thread-- CHANGES.txt-- and
> discuss issues surrounding releasing trunk in a separate thread.
It directly addresses the thread: if one isn’t cherry picking patches
because t
Let's stay focused on the title of the thread-- CHANGES.txt-- and
discuss issues surrounding releasing trunk in a separate thread.
Colin
On Mon, Sep 14, 2015 at 3:59 PM, Allen Wittenauer wrote:
>
> Given that we haven’t had a single minor release in the “stable” era
> of
Given that we haven’t had a single minor release in the “stable” era of
branch-2 that didn’t break compatibility, we should just declare defeat and
make regular releases from trunk as the next 2.x. Then the whole “back port”
thing becomes moot. We’ve already trained users that they ne
On Sat, Sep 12, 2015 at 11:28 AM, Haohui Mai wrote:
> CHANGES.txt is always a pain. *sigh*
>
> It seems that relying on human efforts to maintain the CHANGES.txt is
> error-prone and not sustainable. It is always a pain to fix them.
>
> I think aw has some scripts for option 2
I put some time into this a little while back, doing releasedocmaker
backports from the Yetus branch. IIRC from Allen, we still need to get lint
mode working before it's good to go. Probably a good bit of JIRA cleanup
will be required to get a clean lint run.
On Sun, Sep 13, 2015 at 4:38 AM, Steve
> On 12 Sep 2015, at 20:26, Allen Wittenauer wrote:
>
>
> On Sep 12, 2015, at 12:25 PM, Allen Wittenauer wrote:
>
>>
>> On Sep 12, 2015, at 11:03 AM, Steve Loughran wrote:
>>
>>>
>>> 2. go to JIRA-generated change logs. Though for that to be reliable, those
>>> fix-version fields have to
On Sep 12, 2015, at 12:25 PM, Allen Wittenauer wrote:
>
> On Sep 12, 2015, at 11:03 AM, Steve Loughran wrote:
>
>>
>> 2. go to JIRA-generated change logs. Though for that to be reliable, those
>> fix-version fields have to be 100% accurate too.
P.S.,
https://github.com/aw-altiscale/eco-r
On Sep 12, 2015, at 11:03 AM, Steve Loughran wrote:
>
> 1. audit trunk/CHANGES.TXT against branch-2/CHANGES.TXT; anything in
> branch-2's (i.e. to come in 2.8) is placed into trunk at that location; the
> "new in trunk" runk's version removed
>
> 2. go
CHANGES.txt is always a pain. *sigh*
It seems that relying on human efforts to maintain the CHANGES.txt is
error-prone and not sustainable. It is always a pain to fix them.
I think aw has some scripts for option 2.
I would like to propose option 3 which might be more robust: (1) do a
git log on
I've just been trying to get CHANGES.TXT between branch-2 and trunk more in
sync, so that cherry picking patches from branch-2 up to trunk is more reliable.
Once you look closely , you see it is a mess, specifically:
trunk/CHANGES.TXT declares things as in trunk only yet which are in bra
trunk's CHANGES.txt is missing releases
> ---
>
> Key: HADOOP-11662
> URL: https://issues.apache.org/jira/browse/HADOOP-11662
> Project: Hadoop Common
> Issue Type: Bug
> Components:
[
https://issues.apache.org/jira/browse/HADOOP-11718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen Wittenauer resolved HADOOP-11718.
---
Resolution: Won't Fix
> CHANGES.TXT in trunk is i
Allen Wittenauer created HADOOP-11792:
-
Summary: Remove all of the CHANGES.TXT files
Key: HADOOP-11792
URL: https://issues.apache.org/jira/browse/HADOOP-11792
Project: Hadoop Common
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 actu
it
should make this a lot easier to avoid, as you suggested.
best,
Colin
On Wed, Mar 18, 2015 at 2:32 PM, Andrew Wang wrote:
> 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 writin
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 tr
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 ar
e 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 Hadoop. It causes too many spurious
> conflicts during cherry picks so we just discard the CHANGES.txt p
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 di
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
he tale of woe here:
> >>
> >>
> http://programmers.stackexchange.com/questions/206016/maintaining-svn-history-for-a-file-when-merge-is-done-from-the-dev-branch-to-tru
> >>
> >> Excerpt:
> >> "prior to Subversion 1.8. The files in the branch and
.com/questions/206016/maintaining-svn-history-for-a-file-when-merge-is-done-from-the-dev-branch-to-tru
>>
>> Excerpt:
>> "prior to Subversion 1.8. The files in the branch and the files in
>> trunk are copies and Subversion keeps track with svn log only for
>> sp
. The files in the branch and the files in
> trunk are copies and Subversion keeps track with svn log only for
> specific files, not across branches."
>
> I think that's how the custom of CHANGES.txt started, and it was
> cargo-culted forward into the git era despite not s
files in the branch and the files in
trunk are copies and Subversion keeps track with svn log only for
specific files, not across branches."
I think that's how the custom of CHANGES.txt started, and it was
cargo-culted forward into the git era despite not serving much purpose
any more th
+1 for automating the information contained in CHANGES.txt. There are some
changes which go in without JIRAs sometimes (CVEs eg.) . I like git log because
its the absolute source of truth (cryptographically secure, audited,
distributed, yadadada). We could always use git hooks to force a commit
+1 for generating CHANGES.txt from JIRA and/or git as part of making a
release. Or just dropping it altogether. Keeping it under version
control creates lot of false conflicts whenever submitting a patch and
generally makes committing minor changes unpleasant.
Colin
On Sat, Mar 14, 2015 at 8
Allen Wittenauer created HADOOP-11718:
-
Summary: CHANGES.TXT in trunk is incorrect
Key: HADOOP-11718
URL: https://issues.apache.org/jira/browse/HADOOP-11718
Project: Hadoop Common
Issue
M, Yongjun Zhang wrote:
> Hi Allen,
>
> Thanks a lot for your input!
>
> Looks like problem a, c, d you listed is not too bad, assuming we can solve
> d by pulling this info from jira as Sean pointed out.
>
> Problem b (branch mergers) seems to be a real one, and your approach
Hi Allen,
Thanks a lot for your input!
Looks like problem a, c, d you listed is not too bad, assuming we can solve
d by pulling this info from jira as Sean pointed out.
Problem b (branch mergers) seems to be a real one, and your approach of
using JIRA system to build changes.txt is a reasonably
I think the general consensus is don’t include the changes.txt file in your
commit. It won’t be correct for both branches if such a commit is destined for
both. (No, the two branches aren’t the same.)
No, git log isn’t more accurate. The problems are:
a) cherry picks
b) branch mergers
c
3:01 PM, Sean Busbey wrote:
>
> > So long as you include the issue number, you can automate pulling the
> type
> > from jira directly instead of putting it in the message.
> >
> > On Fri, Mar 13, 2015 at 4:49 PM, Yongjun Zhang
> > wrote:
> >
> > >
un Zhang
> wrote:
>
> > Hi,
> >
> > I found that changing CHANGES.txt when committing a jira is error prone
> > because of the different sections in the file, and sometimes we forget
> > about changing this file.
> >
> > After all, git log would indic
an automate pulling the type
> from jira directly instead of putting it in the message.
>
> On Fri, Mar 13, 2015 at 4:49 PM, Yongjun Zhang
> wrote:
>
> > Hi,
> >
> > I found that changing CHANGES.txt when committing a jira is error prone
> > because of the diffe
So long as you include the issue number, you can automate pulling the type
from jira directly instead of putting it in the message.
On Fri, Mar 13, 2015 at 4:49 PM, Yongjun Zhang wrote:
> Hi,
>
> I found that changing CHANGES.txt when committing a jira is error prone
> because of t
Hi,
I found that changing CHANGES.txt when committing a jira is error prone
because of the different sections in the file, and sometimes we forget
about changing this file.
After all, git log would indicate the history of a branch. I wonder if we
could switch to a new method:
1. When committing
Allen Wittenauer created HADOOP-11662:
-
Summary: trunk's CHANGES.txt is missing releases
Key: HADOOP-11662
URL: https://issues.apache.org/jira/browse/HADOOP-11662
Project: Hadoop C
Kai Zheng created HADOOP-11563:
--
Summary: Add the missed entry for CHANGES.txt
Key: HADOOP-11563
URL: https://issues.apache.org/jira/browse/HADOOP-11563
Project: Hadoop Common
Issue Type: Bug
On Sep 10, 2014, at 6:17 PM, Allen Wittenauer wrote:
> Here’s a (merged) 3.x changes.txt file from the current output built off of
> JIRA. (The unmerged versions are also created, but look pretty much
> identical.)
>
> http://pastebin.com/fEUKSDG4
Woops, that’s only comm
Fixed the subtasks.
Hacked on my changes generator a bit more. Source is in my github repo if
anyone wants to play with it.
Here’s a (merged) 3.x changes.txt file from the current output built off of
JIRA. (The unmerged versions are also created, but look pretty much identical.)
http
FWIW, I’ve gone through a 2nd pass of JIRA for 3.0.0. I’m reasonable confident
that as of this very second that the 155 non-sub-tasks are only in trunk. I
did not do a pass over the 35 sub-tasks claiming to be in 3.x.
Fun fact: the oldest patch is from 2011 and turned 3 years old this month.
On Sep 5, 2014, at 9:19 AM, Karthik Kambatla wrote:
> On Thu, Sep 4, 2014 at 8:37 AM, Allen Wittenauer wrote:
>>
>>We do need to have a talk about 3.x though. Looking over the
>> list, it would appear that a lot of (what became) early 2.x JIRAs were
>> marked as Fixed against 3.x. Pr
; > features?
> >
> > I know that any change is potentially incompatible —but it is still good
> to
> > highlight the things we know are likely to cause trouble
> >
> >
> > On 4 September 2014 02:51, Allen Wittenauer wrote:
> >
> >> Nothing
lly incompatible —but it is still good to
> highlight the things we know are likely to cause trouble
>
>
> On 4 September 2014 02:51, Allen Wittenauer wrote:
>
>> Nothing official or clean or whatever, but just to give people an idea of
>> what an auto generated CHAN
lean 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 e
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:
>
>>
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, Se
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 ar
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 o
[
https://issues.apache.org/jira/browse/HADOOP-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen Wittenauer resolved HADOOP-7365.
--
Resolution: Incomplete
Stale.
> Clean up CHANGES.
is backported to a soon to be
release 2.0.4, the fixVersion must be updated to 2.0.4. Another scenario is
when you have different release lines, i.e 1.x and 2.x (or 2.0.x and
2.1.x), then the fixVersion should contain each line version.
Still, IMO, much better than dealing with CHANGES.txt in
I went ahead and committed a couple of changes to trunk and branch-2 to fix
the MR CHANGES.txt mess. Alexandro, I believe there's a couple of jiras
where you were waiting for CHANGES.txt fixes before merging to branch-2.
Not sure about past discussions, but can we re-visit removing CHANGES.t
I started looking at this yesterday, MAPREDUCE CHANGES.txt is completely
broken. I'll try to fix it and then send out a note once I am done.
Thanks,
+Vinod
On Apr 1, 2013, at 11:46 PM, Vinod Kumar Vavilapalli wrote:
>
> I've been looking at YARN and it seems to be fine. I pr
APREDUCE-5113 to branch-2 I've noticed that the
> CHANGES.txt are out of sync. Commit message are on the wrong releases.
>
> I've spent some some time trying to fix it, but I did not find it straight
> forward to do so.
>
> I assume the same may be true for common, h
while trying to commit MAPREDUCE-5113 to branch-2 I've noticed that the
CHANGES.txt are out of sync. Commit message are on the wrong releases.
I've spent some some time trying to fix it, but I did not find it straight
forward to do so.
I assume the same may be true for common, hdfs an
Suresh Srinivas created HADOOP-9373:
---
Summary: Merge CHANGES.branch-trunk-win.txt to CHANGES.txt
Key: HADOOP-9373
URL: https://issues.apache.org/jira/browse/HADOOP-9373
Project: Hadoop Common
Eli Collins created HADOOP-8771:
---
Summary: Correct CHANGES.txt file
Key: HADOOP-8771
URL: https://issues.apache.org/jira/browse/HADOOP-8771
Project: Hadoop Common
Issue Type: Task
Affects
Siddharth Seth created HADOOP-8743:
--
Summary: Change version in branch-2 to 2.2.0-SNAPSHOT, Update
CHANGES.txt
Key: HADOOP-8743
URL: https://issues.apache.org/jira/browse/HADOOP-8743
Project: Hadoop
unsubscribe
On Nov 21, 2011, at 12:13 PM, Doug Cutting wrote:
> On 11/21/2011 11:49 AM, Matt Foley wrote:
>> The advantage of CHANGES.txt is that it merges when the branch merges. So
>> as long as the developers stick to reasonably normal merge and commit
>> processes, it truly re
On 11/21/2011 11:49 AM, Matt Foley wrote:
> The advantage of CHANGES.txt is that it merges when the branch merges. So
> as long as the developers stick to reasonably normal merge and commit
> processes, it truly reflects what is in the current state of any given
> branch, at least at
It sounds like CHANGES.txt has been helping to resolve issues for Matt, and
taking it away will open the floodgates.
I'm not familiar enough with the Jira procedures yet, but my usual expectation
is that there will be some review between a developer marking the resolution
"resolved&q
Hi Todd,
As you know, one of the tasks of a release manager is to gather a correct
and complete statement of all changes in a release, and include them in the
Release Notes. As I've done the release management for 0.20-security, I've
had the fun of seeing all the deficiencies of both C
On Mon, Nov 21, 2011 at 11:01 AM, Todd Lipcon wrote:
> I was thinking... our use of CHANGES.txt is a bit silly - we basically
> maintain all of our changes in three places (a) JIRA fixVersion field,
> (b) CHANGES.txt, and (c) the SVN changelog. It seems to me that we get
> very litt
I was thinking... our use of CHANGES.txt is a bit silly - we basically
maintain all of our changes in three places (a) JIRA fixVersion field,
(b) CHANGES.txt, and (c) the SVN changelog. It seems to me that we get
very little value out of CHANGES.txt -- the contents are way too large
(and terse
[
https://issues.apache.org/jira/browse/HADOOP-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran resolved HADOOP-7727.
Resolution: Fixed
> fix some typos and tabs in CHANGES.
[
https://issues.apache.org/jira/browse/HADOOP-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eli Collins resolved HADOOP-1787.
-
Resolution: Won't Fix
Out of date
> Reorder CHANGES.txt so that each section is sorte
Remove ref of 20.3 release from branch-0.20 CHANGES.txt
---
Key: HADOOP-7372
URL: https://issues.apache.org/jira/browse/HADOOP-7372
Project: Hadoop Common
Issue Type: Task
Clean up CHANGES.txt
-
Key: HADOOP-7365
URL: https://issues.apache.org/jira/browse/HADOOP-7365
Project: Hadoop Common
Issue Type: Task
Reporter: Owen O'Malley
Assignee: Owen O&#
On Jan 8, 2011, at 4:44 AM, Owen O'Malley wrote:
>
> To prevent future race conditions, let me formally be the RM for 0.20.3.
> Please check with me before any commits to the 0.20 branch.
>
Great news..
Thanks Owen.
> -- Owen
nch seemed very
quiet so I didn't think it was a big deal, sorry about that.
I'm not against 20.3, but I would like to see some discussion and
not have things reverted out of it without discussion.
I *didn't* revert the change. I just moved the description in
CHANGES.txt to 0
mp;view=rev
> Log:
> HADOOP-1734. Move to release 0.20.4 since I already made the tag 0.20.3.
>
> Modified:
>hadoop/common/branches/branch-0.20/CHANGES.txt
>
> Modified: hadoop/common/branches/branch-0.20/CHANGES.txt
> URL:
> http://svn.apache.org/viewvc/hadoop/common/
[
https://issues.apache.org/jira/browse/HADOOP-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom White resolved HADOOP-6969.
---
Resolution: Fixed
I've fixed this.
> CHANGES.txt does not reflect the release of versio
CHANGES.txt does not reflect the release of version 0.21.0.
---
Key: HADOOP-6969
URL: https://issues.apache.org/jira/browse/HADOOP-6969
Project: Hadoop Common
Issue Type: Bug
94 matches
Mail list logo
