[PATCH] sim: switch to autogenerated ChangeLog files

[Andrew Burgess]

* 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!

Thanks,
Andrew