This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/1 V2] manual/time.texi: correct the zoneinfo path
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, J William Piggott <elseifthen at gmx dot com>, <libc-alpha at sourceware dot org>, Paul Eggert <eggert at cs dot ucla dot edu>
- Date: Sat, 14 Feb 2015 17:31:39 +0000
- Subject: Re: [PATCH 1/1 V2] manual/time.texi: correct the zoneinfo path
- Authentication-results: sourceware.org; auth=none
- References: <54B989EA dot 3080307 at gmx dot com> <54CED496 dot 7090905 at gmx dot com> <54DD6E60 dot 1090101 at redhat dot com> <54DE70D9 dot 40203 at gmx dot com> <54DE82D8 dot 4020601 at redhat dot com> <20150213231607 dot 84B932C3C27 at topped-with-meat dot com> <54DEA926 dot 2010201 at redhat dot com>
On Fri, 13 Feb 2015, Carlos O'Donell wrote:
> I will instead take this time to look over again how to do ChangeLog
> auto-generation from commit meta-data, to solve this problem more easily.
I advise looking at the gnulib gitlog-to-changelog script for that
purpose. Things to consider include the handling of commits with multiple
authors for the ChangeLog entry, handling post-commit corrections
(including to authors and dates), choice of date for the generated
ChangeLog entries (commit date is probably better than author date, people
rebasing sometimes end up pushing changes where the author date is months
ago), handling the separate ChangeLogs still used for libidn and
localedata, and distinguishing the long description of the rationale for a
change (which should be included in the commit message, not just the
summary line and ChangeLog entry) from the description of what changed
that goes in the ChangeLog entry.
I'm not sure how much of that gitlog-to-changelog handles, but it seems a
reasonable starting point. And we could always consider such things as
stopping using the remaining subdirectory ChangeLogs, or putting the full
rationale in the generated ChangeLog rather than just the description of
what changed, if desired.
(I suppose "make dist" could no longer use git archive unless the release
process involves committing the generated ChangeLog before tagging /
branching / releasing.)
Joseph S. Myers