Doing away with changelogs

[Jeffrey Hutzelman]

On Wednesday, April 19, 2006 03:07:56 PM -0500 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> What MIT needs to do here is find the sweet spot between too detailed a
> changelog and too empty changelog.

True.  But I happen to believe, based on actual experience trying to get 
information out of other software, that you can approximate the right 
answer by having two sets of information.  One is high-level release notes, 
which are already being prepared, and one is a (fairly) low-level 
changelog, which is easy to generate automatically, at least if your commit 
messages are meaningful (and if the commit messages are _not_ meaningful, 
then you already have a problem).




>> But yes; if your release notes contained an actual description of every
>> change, that would go a long way toward answering both "what caused this
>> problem" and "will this release fix my problem".  Of course, it would
>> also  look an awful lot like a ChangeLog...
>
> Note that Sun includes *synopsis* not *description* text for bugs/RFEs
> fixed in patches and updates.  Why should MIT be any different?

Well, in Sun's case the useful information is usually not in the public 
part of the bug database anyway.  But I agree, a full description of the 
bug and the process of tracking it down, political side-trips, etc. is not 
necessary.  What is useful is a description of the code change, just as one 
would write for a commit message.

Really, that's all we're asking for.  But people keep interpreting that 
request as needing to do some complex task involving integration with bug 
databases and manual massaging for each release.


> What does matter from a development and root causing point of view is
> being able to track changesets to bugs fixed by them and associated
> descriptions.

For _development_, being able to look at descriptions of changesets in svn 
or whatever is useful.

For someone trying to track down a problem introduced by a change from one 
old version to potentially another old version (a process which often 
involves a binary search), possibly considerably after the fact and 
possibly having only the source-release snapshots to work with, it's 
incredibly useful to be able to diff not only the source trees but the 
associated changelogs.

-- Jeff