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: Automating the maintenance of the ChangeLog file

On 11/21/18 8:57 AM, Zack Weinberg wrote:
> On Wed, Nov 21, 2018 at 10:43 AM Szabolcs Nagy <> wrote:
>> On 21/11/18 14:13, Zack Weinberg wrote:
>>> I would like to separate the discussion of *how we could automate
>>> maintenance of the ChangeLog file* from the discussion of *whether we
>>> should keep writing ChangeLog entries, by hand or with some level of
>>> machine assistance*.  The value of writing a traditional ChangeLog
>>> entry for each commit is contentious even within this project, and any
>>> change would require arguing with GNU upper management who may be even
>> why do you say it's contentious?
>> i don't see anybody arguing for manually writing changelog.
> Andreas Schwab has, in the other thread.
>> (there seems to be agreement that the only point of the ChangeLog is
>> to please RMS, which we can do by generating it when creating the
>> release tarball)
> That's not what it looks like to me.
>> (your comment that it's useful for catching bugs by
>> a submitter are not relevant to the contribution process)
> True.
>> writing the changelog entry is what takes time,
>> copying that boilerplate around does not matter much,
>> so i don't see a significant gain with that approach.
> Perhaps because I find writing the changelog entry to be a useful
> bug-catching exercise, I don't mind the time it takes.  But I do very
> much mind having to remember to rebase an approved patch series, edit
> the actual changelog file in each commit, copy and paste the text out
> of the commit message.  Without that, the process of pushing an
> approved patch series would be a string of commands that I can rattle
> off without thinking about them.  With it, it takes multiple manual
> actions for each patch in the series and it's easy to make mistakes.
> That's what I care about eliminating, and I'm frustrated that a
> GNU-level policy change that may never be accomplished is blocking it.
Agreed 100%.  This is precisely where I want to see GCC go in the short
term as well.

Like you, I find writing the ChangeLog useful in that I'm forced to look
at my change again and I regularly see something that I think ought to
be fixed and run through another test cycle.

But the insanity of actually putting it into a ChangeLog file, dealing
with rebases/conflicts as a result is just silly, particularly when we
could just include the data in the commit message and have tools to
extract them from commit messages for those who find reading ChangeLogs
useful (such as myself).

I haven't really got any traction on that for GCC though.


> zw

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