This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: David Miller <davem at davemloft dot net>
- Cc: <siddhesh dot poyarekar at gmail dot com>, <normalperson at yhbt dot net>, <carlos at redhat dot com>, <pasky at ucw dot cz>, <roland at hack dot frob dot com>, <neleai at seznam dot cz>, <libc-alpha at sourceware dot org>
- Date: Wed, 27 Mar 2013 16:55:57 +0000
- Subject: Re: ChangeLog entry complexity
- References: <Pine dot LNX dot 4 dot 64 dot 1303261741360 dot 8202 at digraph dot polyomino dot org dot uk> <CAAHN_R34fC5CEy0E991QjsBd_7X9wOwdw1_OV+PiV-thi0E4Kg at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1303271410180 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 122142 dot 866614393146675379 dot davem at davemloft dot net>
On Wed, 27 Mar 2013, David Miller wrote:
> From: "Joseph S. Myers" <joseph@codesourcery.com>
> Date: Wed, 27 Mar 2013 14:26:28 +0000
>
> > ChangeLog entries provide a useful level of description of changes
>
> Which can be more effectively reproduced, with the searcher's desired
> level of detail, using the source code control system we use.
If you define machine-parseable conventions for formatting log messages to
provide the human-level descriptions of the changes to each part of the
code, then you're not actually saving any effort compared to that for
writing a sensibly evolved version of ChangeLog entries (i.e. one where
the "why" is included alongside the "what", and global changes detail
things at the function / file level only where that's a useful level of
description for the patch in question).
I think having such fully-defined conventions that allow automatic
ChangeLog generation would be reasonable, but automatic ChangeLog
generation itself (with gitlog-to-changelog or similar, including
processes for corrections to past log entries) would only be effective for
the goal of source trees always carrying information about what changes
are in them (when passing through tarballs, different VCSes etc.) if
things could be configured so that checkouts automatically include the
automatically updated ChangeLog file (without special client-side
configuration being needed). ChangeLog generation only at release time is
much less satisfactory.
--
Joseph S. Myers
joseph@codesourcery.com