2.37 branch and ChangeLogs

[Mike Frysinger]

On 18 Jun 2021 13:36, Alan Modra via Binutils wrote:
> On Thu, Jun 17, 2021 at 09:25:27PM -0400, Mike Frysinger via Binutils wrote:
> > On 17 Jun 2021 16:30, Hans-Peter Nilsson wrote:
> > > On Thu, 17 Jun 2021, Nick Clifton via Binutils wrote:
> > > >   Once the 2.37 branch has been created, we are going to relax the
> > > >   requirement that patch submissions include text for changelog
> > > >   entry(s).  Instead we are going to use the details from the git commit
> > > >   messages.  This does mean that these messages must include accurate
> > > >   details concerning the author(s) and contents of the patches.
> > > >
> > > >   Changelog entries can still be submitted with a patch, should the
> > > >   author so wish, but the commit messages must also be complete.
> > > >
> > > >   I will be investigating how to collect together git commit messages
> > > >   and turn them into changelog like files for when a release is
> > > >   generated, so that releases will still retain full details of the
> > > >   patches that they contain.
> > > 
> > > I endorse re-using the GCC solution, with complete, formatted
> > > changelog entries as part of the git commit log and automated
> > > extraction to the respective ChangeLog (piggy-backed on the
> > > snapshot scripts).  Or, at least something compatible with the
> > > corresponding workflow, so maintainers don't have to remember
> > > that the rules are different.
> > > 
> > > I hope the practical problems are manageable with different
> > > rules in gdb and binutils and whatnot with the different
> > > directories.
> > 
> > gdb & binutils are in sync now.  gdb is getting rid of ChangeLogs entirely,
> > both as files & in commit messages.
> > https://sourceware.org/pipermail/gdb-patches/2021-June/179872.html
> > 
> > this is vastly superior to gcc's flow.
> 
> I'm more than happy to be rid of ChangeLog files, but I don't agree
> that gdb's scheme is vastly superior.  You don't know that yet.  How
> many people downstream of gdb, who perhaps only look at gdb source
> from one release to the next, will have their workflow affected?  One
> such group of people are FSF lawyers, who might need to defend you
> against another SCO.  Is the FSF happy with the change?
> 
> Like Hans-Peter, I also think binutils would be better adopting gcc's
> scheme at least in the near future.  It's easy to follow, and I reckon
> binutils putting ChangeLog entries into the git log won't impact gdb.
> 
> As far as patch submissions go, I won't reject a patch without a
> ChangeLog; I've often filled one out for new contributors.  
> 
> Note that my work-flow won't be affected much if we lose ChangeLog
> entries entirely.  I don't tend to use ChangeLogs nowadays when doing
> source archaeology.  It's the legal side of this change that is
> bothering me.

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.
-mike