Re: Towards Meargeable patch submissions for glibc

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 3 Sep 2018, Siddhesh Poyarekar wrote:

> GNU Tools Cauldron 2018 is upon us and it is once again time to discuss
> dropping ChangeLogs!

Since I think it's the ChangeLog format that's the main problem rather 
than the need to edit the ChangeLog file manually, I think that rather 
than writing a script to auto-generate the ChangeLog file it would be 
better to write a script to list the named entities changed in a commit 
(more accurately than simply looking at diff hunk headers - in particular, 
where the funcname line is inside the diff hunk or where it's a macro 
definition being changed rather than something that gets properly 
identified for diff hunk headers).  The main purpose of that script would 
not be for people actually to run it to list changed entities, but simply 
by its existence to justify a change to the GNU Coding Standards to stop 
requiring ChangeLog format 
<https://lists.gnu.org/archive/html/bug-standards/2018-05/msg00003.html> 
<https://lists.gnu.org/archive/html/bug-standards/2018-05/msg00011.html>.  
(If they still require a ChangeLog *file* in release tarballs after that, 
such a file could be generated more or less trivially, e.g. "git log 
--stat <last-release-tag>..HEAD > ChangeLog" as the last thing done before 
a release, and "mv ChangeLog ChangeLog.old/ChangeLog.<number>" as the 
first thing done after a release.)

> We should also do something similar for NEWS entries.  We can work that out
> during Cauldron since the solution will be similar to this one.

I don't think this is relevant for NEWS entries; editing the NEWS file 
directly seems appropriate for those.

-- 
Joseph S. Myers
joseph@codesourcery.com