This is the mail archive of the
mailing list for the glibc project.
Re: Towards Meargeable patch submissions for glibc
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
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
(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.