This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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
(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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]