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