On Tue, May 27, 2003 at 12:46:02AM -0400, Matt Zimmerman wrote: > > * Matt Zimmerman <[EMAIL PROTECTED]> [030526 21:41]: > > > It is _not_ obvious, and "closes: #..." gives no clue to someone reading > > > the changelog what might have been changed. Internet access, knowledge > > > of debbugs, etc. are not prerequisites for being able to make use of a > > > changelog. > > > > Then why do you limit your critic to the bug closed. Which bugs are closed > > are often the least interisting item of a new version. > > Bug fixes are one of the most interesting things in a changelog. This is > not the daily news, it is a record of what changed, and _when_.
It should be possible, for example, for me to read the changelog from a version of a package in unstable and from that to be able to judge whether it's worthwhile installing that version of the package on my stable system. This means I need to know what bugs have been fixed and when, and what scary new features have been added, and when. There's no way I'm going to be able to keep track of it by looking up every bug that's been fixed in that time in the BTS. Alternatively, I might want to work out why a package might depend on a specific version of your package -- for example when trying to backport the other package to stable. If you have a decent changelog I can quickly and easily judge whether the fixes that were introduced in the version mentioned in the dependency are necessary to me or not. If your changelog merely says "New upstream version, closes: #123 #456", it's no help whatsoever, and I will (rightly) think that you suck. FFS, it's a *change*log -- so log the effing changes in it. Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Do not overtax your powers.