This is the mail archive of the
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.
Requires paying attention to detail
Can be fixed post commit
Distributed in tarballs
Can grep for file name or function
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.