Home Original page

2.37 branch and ChangeLogs

Carlos O'Donell carlos@redhat.com
Wed Aug 4 21:26:17 GMT 2021 
On 6/18/21 2:28 AM, Alan Modra via Binutils wrote:
> On Fri, Jun 18, 2021 at 12:56:39AM -0400, Mike Frysinger wrote:
>> the existence of the ChangeLog entry spam in the commit message is orthogonal
>> to your point about having some sort of audit trail in released sources.  i
>> agree shipping the git log in the release tarballs is a good idea, but that
>> doesn't mean we need to waste any more developer time and energy on ChangeLog
>> entries.  hence, it is superior to the gcc flow.
> 
> Heh, the gdb essays in git commit messages used to annoy me a little
> when looking for binutils changes, until I discovered
>   git log bfd opcodes binutils gas ld gprof
> or variants of that.  :-)

Right, and there are technical ways to solve this with subdir prefix standards
for the first line of the commit message e.g. bfd/.
 
> More seriously, if the FSF is OK with what gdb is intending, I'm happy
> enough to go along too.

In glibc we use gnulib vcs-to-changelog to generate the ChangeLog:
https://sourceware.org/glibc/wiki/Release/#First_Tag_.5BREQUIRED.5D_.28At_release.29

This was vetted and discussed with the GNU Project:
https://sourceware.org/pipermail/libc-alpha/2019-January/100645.html

I support Mike's position that:

* Nobody should write ChangeLog messages anymore.

* ChangeLog's generated for the release tarball can be done in an automated
  fashion and glibc has a successful process for that and support from
  stakeholders to deploy that process.

It is my hope as a GNU Toolchain developer that all the core projects could
move in that direction.

-- 
Cheers,
Carlos.
More information about the Binutils mailing list