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 > > > > > >
