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 the above welcome as always. Best, Andrew On Wed, Mar 2, 2016 at 9:46 PM, Akira AJISAKA <ajisa...@oss.nttdata.co.jp> wrote: > 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 >>> >>> >>> >>> >>> >>> >>> >> >
