Re: [PATCH] sim: switch to autogenerated ChangeLog files

[Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>]

On 12 Jan 2021 10:47, Andrew Burgess wrote:
> Mike Frysinger <vapier@gentoo.org> [2021-01-11 14:38:30 -0500]:
> > On 11 Jan 2021 12:00, Simon Marchi wrote:
> > > On 2021-01-11 6:05 a.m., Andrew Burgess wrote:
> > > > I think sim/ should follow the same policy as gdb/ for now.  Do feel
> > > > free to raise this as a suggestion for gdb/ in general though, it
> > > > would be an interesting conversation to observe.
> > > 
> > > Last time I tried the gitlog-to-changelog script on GDB, it produced
> > > horrible results.  Probably because it was not designed for C++.
> > > 
> > > Making a script to produce ChangeLogs for C code is already very
> > > difficult, making it work with good results for C++ would be even
> > > worst.  And most importantly, I think it would be wasted development
> > > time.
> > 
> > to be clear, it isn't generating entries exactly like we write.  it's
> > using the git commit logs with formatted dates.  so i don't think this
> > applies exactly anymore.  so it's inline with the GNU's VCS principles:
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html
> > (and that also recommends just using gitlog-to-changelog).
> 
> I read this page, and especially the part that talks about using
> gitlog-to-changelog, and I don't find their argument compelling.
> 
> Early in the page they list some uses for ChangeLogs, which basically
> boils down to performing "software forensics".  Their benefits are all
> good, but IMHO are all covered (and covered better) by what the VCS
> provide.
> 
> At the end of the page they say if you don't maintain a ChangeLog then
> use a script to generate one in case people want to look at the
> ChangeLog.  But they fail to explain what use a ChangeLog is in a
> release tree.  The same argument could just as easily be used to
> justify including a poem in the release; it should be there in case
> someone wants to look at it.
> 
> For me the question is what benefit does a ChangeLog offer in a
> release tree?  When I look through the 7 points (in favour of
> ChangeLogs) raised on the above page I don't see what value any of
> those things have given only a release tree.
> 
> If we really wanted to include something informative inside each
> release then I'd be most tempted to just do something like:
> 
>    git log --stat last-release-tag...new-release-tag > GIT-LOG
> 
> That would give people a far more detailed understanding of what has
> changed.
> 
> But honestly, I don't think it's unreasonable to say that if someone
> wants to dig into the source history, just clone the repo.... and let
> ChangeLogs burn!

so how are we feeling now ?  i think we agree that we don't want to hand
maintain ChangeLog files.

then we need to decide on whether we want to include ChangeLog files for
sim/ at all in releases.  i'd be fine with just dropping them entirely if
we don't want to bikeshed it anymore.  we can create a sim/ChangeLog that
just reads:
  Please see the git log online at:
  https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=sim

if we do include them, i think it's reasonable to expect they take a form
similar to the other ChangeLog files in the tree.  that would mean using
gitlog-to-changelog, or some other gnu tool that i've missed.  the upside
to that over a raw `git log` is that, for old commits, it wil extract any
ChangeLog entries and inline them in the log.  this would be an easy way
to bridge the old & new ways of writing log entries.
-mike