On Sat, Sep 12, 2015 at 11:28 AM, Haohui Mai <ricet...@gmail.com> 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 would like to propose option 3 which might be more robust: (1) do a > git log on the branch to figure out the jiras that are committed to > the branch. and (2) generate CHANGES.txt by going through these jiras. > That might eliminate the fix-version issue.
+1000. CHANGES.txt is a huge pain when doing backports (even just from trunk to branch-2) and is much more unreliable than a simple "git log." We should just have a script to generate this file during the release, similar to releasenotes.txt. In the rare case where git log is wrong (because of an incorrect commit message or something), we can have a side file checked into the repo containing corrections that the CHANGES.txt script can read and use to modify the git log. best, Colin > > I can volunteer some effort to help on this. > > ~Haohui > > > On Sat, Sep 12, 2015 at 11:03 AM, Steve Loughran <ste...@hortonworks.com> > wrote: >> >> 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 branch-2 >> and/or actual releases >> >> >> What to do? >> >> 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 to JIRA-generated change logs. Though for that to be reliable, those >> fix-version fields have to be 100% accurate too. >> >>
