This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: ChangeLog entry complexity
- From: Allan McRae <allan at archlinux dot org>
- To: libc-alpha at sourceware dot org
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, David Miller <davem at davemloft dot net>, 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
- Date: Fri, 29 Mar 2013 11:51:39 +1000
- Subject: Re: ChangeLog entry complexity
- References: <Pine dot LNX dot 4 dot 64 dot 1303271427040 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 122444 dot 1693913000175389808 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1303271628190 dot 23096 at digraph dot polyomino dot org dot uk> <20130327 dot 125821 dot 1593463415239280090 dot davem at davemloft dot net> <Pine dot LNX dot 4 dot 64 dot 1303271701550 dot 23096 at digraph dot polyomino dot org dot uk> <20130328043009 dot GB17540 at spoyarek dot pnq dot redhat dot com>
Given this thread is now 40 messages long, I decided to read through and
make a summary of the pros/cons to keeping ChangeLogs that have been
mentioned so far.
Pros:
Requires paying attention to detail
Can be fixed post commit
Distributed in tarballs
Machine parsable
Can grep for file name or function
Cons:
Resources spent on writing/editing ChangeLog entries
Merging is more difficult
git log/blame is "equivalent"
Makes refactoring difficult (long ChangeLog entries)
Do not provide detail needed to understand the change (why/how)
ChangeLogs are incomplete
The only thing that I will add is that I find it rather difficult to
find the "why" of many changes - although it is better now that we
enforce all but trivial patches to go via the mailing list, so there is
some (although far from ideal) reference there.
Allan