Re: Using the vcs_to_changelog.py script

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2020-02-13 2:29 p.m., Eli Zaretskii wrote:
>> From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
>> Cc: binutils@sourceware.org, gdb-patches@sourceware.org
>> Date: Thu, 13 Feb 2020 20:09:21 +0100
>>
>> On Thu, 2020-02-13 at 20:58 +0200, Eli Zaretskii wrote:
>>> I have yet to see this accepted as GNU policy.  And at least
>>> personally, having a ChangeLog in a tarball that just says which
>>> function was changed on what date is almost useless to me (and I do
>>> sometimes need to work without access to the VCS repositories).
>> It looks easy to have a script to generate a file that contains all
>> the git log messages + the diff for each commit
>> in case detailed changes have to be analysed off-line, without a git repository.
> 
> How does this help when all you have is the release tarball?

I think Philippe suggests bundling that file in the release tarball, similar to how we
would be bundling the ChangeLog file.

If we were to do that, I'd suggest instead to run "git-format-patch" on
the range of commits included in the release.  That generates one file
per commit (with a numerical prefix so they are in the right order), which
makes it easier to consult.

The problem with this might be the size of that content.  I tried just for
fun to see how big it would get with the gdb 9 release.  I generated the files
with this command:

  git format-patch $(git merge-base gdb-8.3-branch gdb-9-branch)..gdb-9-branch

2990 patch files are produced.  The result is 115M uncompressed,
11M gzip-compressed, 6.7M xz-compressed.  So it's not that bad, considering the
amount of information it contains.

> 
> Anyway, I really don't think we should re-iterate the many months of
> discussions on gnu-prog-discuss, which led me to propose the change in
> standards.texi.  Those discussions have beaten this horse to death,
> and I don't think we will invent any new arguments for or against
> producing ChangeLog files from VCS logs.  If we decide to produce
> ChangeLog files at the time the release is tarred, then the ChangeLog
> files should be informative and useful; otherwise it's tantamount to
> deciding to drop ChangeLog's for the releases as well.

Agreed.

Simon