Re: ChangeLog entry complexity

[Mike Frysinger <vapier at gentoo dot org>]

On Monday 11 March 2013 17:43:22 Petr Baudis wrote:
>   (My personal view is that ChangeLog is just too expensive to maintain.
> When investigating the history, I always used 'git log' anyway except
> for the CVS-imported history, and maybe sometimes turn to ChangeLog for
> extra information, but this could be just kept in the commit message.)

i think the ChangeLog files are entirely superfluous noise that add nothing to 
the code base, yet are a pita to generate/maintain/rebase/etc...

the concept made more sense when using a crap VCS (i.e. cvs or rcs) as there 
wasn't an easy way to revert a change that touched multiple files.  the 
ChangeLog file provided you a blueprint of sorts so you could rollback.  the 
GNU page indicates as much as part of its reasoning:
http://www.gnu.org/prep/standards/html_node/Change-Log-Concepts.html

however, when paired with a reasonable VCS (i.e. git), a properly written 
commit message with the diffstat is all that is necessary for anything you want 
to do.  if the stat is too big, or the message doesn't cover the logic, then 
those are problems that can be solved by splitting the CL or improving the 
commit message.  plus, using a ChangeLog file wouldn't help in those cases.

i don't buy into the idea that requiring people to generate them is instilling 
anything useful.  i copy & paste the vast majority of my entries and 
autogenerate whenever possible.  even the GNU site provides suggestions on how 
to autogenerate things.  it is entirely a waste of my time and why i often 
don't even bother doing it until just before i commit (since any 
review/feedback will induce code/file changes which invalidate the previously 
generated ChangeLog entries).
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.