Re: Towards Meargeable patch submissions for glibc

[Siddhesh Poyarekar <siddhesh at gotplt dot org>]

On Monday 03 September 2018 07:17 PM, Joseph Myers 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.)

I agree that is the ideal place to be in but it seems much harder to 
auto-generate a full ChangeLog entry in that manner and not something I 
personally want to take up, compared to simply gleaning a manually 
written ChangeLog entry from the commit log.

The proposal is to decouple this from the more immediately solvable 
problem of being able to cherry-pick commits across branches and make 
them more amenable to patch review tools so that we can make that 
process a bit more flexible.

That is, it is less about ChangeLog formats and more about getting it 
out of the patch body.  Would you be in favour of this decoupling?

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

Yeah the auto-generation is not, but when it comes to cherry-picking 
commits across branches it becomes a bit clumsy.  But I suppose it's not 
as big a problem as the ChangeLog which affects *every* commit and we 
could deal with it if it is ever seen as a problem later.

Siddhesh