This is the mail archive of the
mailing list for the glibc project.
Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: libc-alpha at sourceware dot org, carlos at redhat dot com, roland at hack dot frob dot com, joseph at codesourcery dot com
- Date: Wed, 5 Aug 2015 06:03:52 +0530
- Subject: Re: Hash out a solution for ChangeLog/NEWS at the Cauldron?
- Authentication-results: sourceware.org; auth=none
- References: <20150804173912 dot GC2504 at spoyarek dot pnq dot redhat dot com> <55C0FCC4 dot 7080603 at cs dot ucla dot edu>
On Tue, Aug 04, 2015 at 10:56:20AM -0700, Paul Eggert wrote:
> We already do something like this for GNU Emacs, for Coreutils, for Grep,
> etc. All of these projects generate ChangeLog files from the commit log. I
> suggest looking at Jim Meyering's gitlog-to-changelog script that comes with
> Gnulib. It handles Signed-off-by:, Co-authored-by:, and
> Copyright-paperwork-exempt: tags.
Awesome, this makes things much easier. I'll take a look and make a
similar proposal for glibc.
> The Emacs developers have a more-conservative approach, which involves not
> just automatically generating ChangeLogs from git commit logs, but also
> makes it easy to do manual edits to the generated ChangeLogs later, to allow
> "changing history". (The Gnulib script also does this, but in a way that's
Great, that solves my problem of an incorrect commit log potentially
generating an incorrect ChangeLog file.
> harder to use.) This is a wrapper around the Gnulib script, which also
> supports a few other features specific to Emacs ChangeLog files. See
> Emacs's build-aux/gitlog-to-emacslog script. Emacs identifies bug numbers
> by having strings of the form "Bug#234234" somewhere in the commit log;
> other projects tend to use "http://bugs.gnu.org/234234".
We already have a similar convention to automatically update the bug
in bugzilla, so it should not be too hard to use that information to
generated a list of bugs fixed for the release.
> Generating NEWS automatically might be a tougher nut to crack; not sure it's
> worth it.
Joseph has a preference for maintaining the file with the NEWS items
and I think that is fine. The release process could simply make the
bug number list and prepend that to the NEWS file.