Re: Using the vcs_to_changelog.py script

[Simon Marchi <simon dot marchi at polymtl dot ca>]

On 2020-02-12 10:37 p.m., Eli Zaretskii wrote:
> Several things we'd need to consider if we go this way:
> 
>  . AFAIK, the script you mention currently supports only C sources;
>    we'd need to see how well it supports C++

We'll see.  The script is not perfect for C (it would be nearly impossible
for a script to be as good as a human to generate these entries), so it
won't be for C++ either.  We can of course improve it as we go.  For simpler
changes, it seems fine, but for example we can see that it got confused for
this change here:

2020-02-12  Tom Tromey  <tom@tromey.com>

	COMMIT: 219823045622bd111d68b984e31aa7b1712d5e10
	Remove the objfile backlink from comp_unit

	* gdb/dwarf2/frame.c: Modified.
	[GDB_SELF_TEST](execute_cfa_program_test): Modified function.
	(comp_unit): Modified.
	(execute_cfa_program): Modified function.
	(while): Modified function.
	(execute_cfa_program): Modified.
	(execute_cfa_program): Modified.
	(execute_cfa_program): Modified.
	(if): Modified function.
	(execute_cfa_program): Modified.

>  . Some files in our tree are neither C++ nor C: there are Python
>    files, Guile files, shell scripts, and Texinfo files, to mention
>    just a few: what to do about them?

I presume glibc is in the same situation... The script just says that
the file is modified.  If we wanted to get more details for them, we
would have to implement new parsers to figure out what changed between
two revisions.

>  . Last, but not least: we'd need detailed instructions for how to
>    produce the commit log messages under this regime, because the old
>    conventions will not be valid anymore.

What are you specifically referring to?  For GDB, I don't really see what
would need to change.  We already enforce having detailed commit logs that
explain:

- the rationale for the change
- technical details about the fix, if not trivial

So the only difference is that we would not provide a manual ChangeLog entry.

Simon