Re: Is it time to drop ChangeLogs?

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Fri, 08 Jul 2016 16:02:29 +0200
> Cc: address@hidden
> 
> Richard Stallman <address@hidden> writes:
> 
> >   > GNU ChangeLogs, as used in practice, are so lame and thin on content
> >   > that they certainly can't be taken seriously as a method of documenting
> >   > changes.
> >
> > They are good for their purpose, which is to summarize which functions
> > or objects were changed, when, and by whom.  That's useful when
> > you want to see which changes to look at to figure out when a bug
> > got introduced.
> 
> That information is already available from the VCS, on steroids. You can
> query the history of a function, ask which changes introduced or deleted
> a call to certain function...

Yes, but doing so on a large file that saw many changes is relatively
slow.  Scanning a ChangeLog is much faster, so I always use it as the
first approximation, and only go to the likes of "git log -L" and
"git annotate" if I have to.

> But the real damage ChangeLogs cause is their formulaic, almost mechanic
> aspect: people write a lot of minutiae instead of writing a commit
> message intended to help the reader, the same way good code comments are
> written. It is true that some hackers write good commit messages *and*
> ChangeLogs, but I'm under the impression that most people just write the
> changelog and consider that their job is done (after all, current policy
> for commit messages is to write a summary line and the 

You are invited to look at our recent commit log messages, which are
in the ChangeLog format, and point out the ones that fit the above
description.  I don't think you will find a lot of them, but maybe I'm
mistaken.

> In a nutshell, a proper commit message shall contain, either explicitly
> or implicitly, the what, why, where and how of the change. It must be
> informative and provide the info that the reader is interested on,
> without entering on unnecessary detail (the diff is readily available,
> there is no need to name each function touched by the change). The
> author must write it with the same mindset he chooses function and
> variable names, decides when it is a good idea to put a code comment,
> etc.

This conflates several distinct places where this information is held,
making it sound that all of it should be in the commit log message.
That is false, or at least I couldn't disagree more.  First and
foremost, the code should speak for itself, so the most detailed
explanations should be in comments there.  We didn't just replace the
code by the VCS!

Second, many times the information is in a prolonged discussion, in
particular on the bug tracker.  By including a reference to the bug
report, we implicitly include all of it in the log message.

As for "the diff is readily available, there is no need to name each
function touched by the change" part, it is inaccurate: the VCS diff
tool doesn't always show the name of the function or macro that is
being changed.  Moreover, if several functions/macros are changed in a
single hunk, at most one of them will be named in the hunk header, the
rest need to be deduced by painfully reading the diffs.  I don't think
we can say in good faith that this information is as readily available
as in ChangeLog-style log messages.

> Some times, however, the code is not the best place to put some
> explanation (think of an scattered change or why some alternative that,
> at first, seems more adequate was discarded) and the commit message
> offers an alternative. The commit message is a good place to direct the
> reader to the key areas for understanding the change, inform the reader
> about current status and future steps and any other info that the author
> thinks is relevant for current and/or future hackers with an interest on
> the affected area.

I find comments to be a better place for these situations as well (and
made many comments of this kind over the years myself).  The most
important reason is discoverability: when one reads code, they usually
won't look at the Git history of the code they go through, but
comments they will see.  Scattered changes are not a problem, you can
always say "see such-and-such function".

> >   > GNU ChangeLogs always looked to me as cargo cult and an excuse for not
> >   > writing proper commit messages.
> >
> > There was no such thing as a commit message in 1985.
> 
> Exactly. I'm pretty sure that if you had a good VCS at that time
> ChangeLogs would never came into being.

If history went another way, perhaps we wouldn't have Emacs as well.

More to the point, fact is that no better methodology was invented.
So history is not the only reason why we are still using this format.