This is the mail archive of the
mailing list for the glibc project.
Re: Automating the maintenance of the ChangeLog file
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>
- Date: Wed, 21 Nov 2018 15:43:39 +0000
- Subject: Re: Automating the maintenance of the ChangeLog file
- References: <CAKCAbMhbPBoCpxv1M5qUjkh-D+kCeU0pw6PvwUg7vC+eOKCYgg@mail.gmail.com>
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.
(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, your comment that it's useful for catching bugs by
a submitter are not relevant to the contribution process: submitters
are always free to do whatever exercise they deem useful for catching
more bugs, such as running build-many-glibcs.py for all targets, but
we don't require that.)
> more attached to them than some of us are. Maintaining the ChangeLog
> file by hand, however, is 100% make-work that makes landing patches
> more difficult than it should be, and we could automate it in short
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.
> order with one policy change that we can make ourselves and should be
> far less contentious, plus some code.