Doing away with changelogs
jhutz at cmu.edu
Wed Apr 19 16:22:04 EDT 2006
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
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
More information about the krbdev