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 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
happy if someone else wants to take it up.

Best,
Andrew

On Wed, Mar 2, 2016 at 8:06 PM, Karthik Kambatla <ka...@cloudera.com> wrote:

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" <
andrew.w...@cloudera.com> wrote:










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 like this mismatch, and it also adds additional overhead to the RM
process. Release dates can also easily be found via the website.

Would anyone object if we dropped this step from the HowToRelease process?

Thanks,
Andrew








Reply via email to