This is the mail archive of the
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: "Ryan S. Arnold" <ryan dot arnold at gmail dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 26 Mar 2013 13:13:39 -0500
- Subject: Re: ChangeLog entry complexity
- References: <20130224085129 dot GA5898 at domone dot kolej dot mff dot cuni dot cz> <20130311132836 dot GA6016 at domone dot kolej dot mff dot cuni dot cz> <20130311162425 dot DAD282C083 at topped-with-meat dot com> <20130311174341 dot GA28265 at domone dot kolej dot mff dot cuni dot cz> <20130311174940 dot 0E0512C08D at topped-with-meat dot com> <513E4924 dot 4010500 at redhat dot com> <20130311214322 dot GC31274 at machine dot or dot cz> <20130311214635 dot 5B9D32C08F at topped-with-meat dot com> <20130325164624 dot GA6137 at machine dot or dot cz> <51508192 dot 90702 at redhat dot com> <20130325205300 dot GA24293 at dcvr dot yhbt dot net> <Pine dot LNX dot 4 dot 64 dot 1303261741360 dot 8202 at digraph dot polyomino dot org dot uk>
On Tue, Mar 26, 2013 at 12:55 PM, Joseph S. Myers
> I think we *should* move to putting both title lines (as explicitly
> described in the GNU Coding Standards) and rationale at the top of
> ChangeLog entries, in addition to the descriptions of "what" changed, and
> also putting that detailed patch description in the commit messages. But
> this would require that the detailed description be reviewed for
> formatting and English usage in as much detail as the rest of the patch.
> It would also mean that many patch submissions could have just the
> ChangeLog entry and patch, without anything else above the ChangeLog
> entry, as the entry would show the full rationale. (Revised submissions
> would still have descriptions of the changes in that particular version
> above the log entry, then the full, possibly amended, rationale in the
> ChangeLog entry.)
Seeing the following sort of thing in ChangeLogs is redundant to what
can be discovered in git and actually says nothing to me about what
the actual changes are for. I'd love to see it go away. Or in lieu
of that, I'd like to see your idea make it obvious what these new
files actually do.
* <some_extermely_complicated_file.c>: New file.
Regarding Commit message formatting and English Usage.. the way it
currently stands, we don't get a second chance on commit messages. I
like your idea. Yes it's more work BUT competent committers can be
relied upon to amend problems in these entries when they're identified
(maybe long after the fact). I'm not sure how much consensus we'd
even need on most of these type of changes. It might even be nice to
be able to put bugzilla numbers into these sections after-the-fact.
Ryan S. Arnold