This is the mail archive of the
mailing list for the glibc project.
Re: Automating the maintenance of the ChangeLog file
On Wed, Nov 21, 2018 at 10:43 AM Szabolcs Nagy <Szabolcs.Nagy@arm.com> 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)
> 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.