Hadoop has a script to generate CHANGES.txt. That might be an option. Agree with Venkatesh. This is an important information and should not be deleted.
On 1/20/16, 10:55 AM, "Seetharam Venkatesh" <[email protected]> wrote: >I think this is quite useful and AFAICT, the release timelines are >quarterly, it might be worth the extra effort to maintain this. > >-1 from me. > >On Wed, Jan 20, 2016 at 10:52 AM Ajay Yadava <[email protected]> >wrote: > >> Currently we are maintaining CHANGES.txt to record contributions, >> committers of the commits and the release in which they got committed. >>All >> this information is also available in JIRA and git. >> >> However, there are certain disadvantages of CHANGES.txt, every time >>during >> release we have to maintain different CHANGES.txt in master and branch. >>We >> have to be careful with subtle details like "Proposed release version" >>and >> "Released version" etc. This also creates confusion when same commit >>gets >> committed into master and the branch. >> >> Also, it entails committers to do some edits to the patch submitted by >>the >> contributor. This is error prone and can be tedious sometimes. >>Sometimes we >> forget to attribute contribution or spell contributor's name >>incorrectly. >> >> Hence I propose to delete CHANGES.txt from master (0.10 onward). Please >> provide your inputs. If everyone agrees, then I will create a JIRA and >> delete CHANGES.txt from master. >> >> >> Cheers >> Ajay Yadava >>
