hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Haohui Mai <ricet...@gmail.com>
Date Sat, 12 Sep 2015 18:28:02 GMT
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.

I can volunteer some effort to help on this.


On Sat, Sep 12, 2015 at 11:03 AM, Steve Loughran <stevel@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
> 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.

View raw message