Christian Marillat <[EMAIL PROTECTED]> writes: > Package: libgtk2.0-0 > Version: 2.8.17-1 > Severity: serious > Justification: Policy 4.4
> Hi, > Apparently you don't understand (or don't care), because this is the > second time I file the same bug report (#344125), but as this package > isn't a native package the upstream changelog should not be here. While in this particular case I think the level of detail is possibly overkill, the Debian changelog file is in a standard format (unlike upstream) and therefore can be parsed and shown by automated tools from apt-listchanges to the QA pages and the upload notifications. Accordingly, I think it is the appropriate place to record any *important* changes to the package, whether they were made upstream or by the Debian package maintainer. This particularly includes changes that someone trying to analyze the history of supported major features or critical bugs is likely to need to know about. Accordingly, for my packages, I mention (as sub-bullets to the "* New upstream release" bullet) any upstream change that: * Closes a Debian bug (and include the bug closer). * Is a major feature enhancement or a major bug fix likely to be of interest to a substantial percentage of the users of the package. * Is of special interest to Debian users. (Requiring configuration changes or changes in the way the package is used in Debian that aren't quite worthy of a NEWS.Debian entry, for instance.) I'm happy to take criticism on what I mention and don't mention, but I personally find Debian changelogs that never mention *any* details of why a new upstream version was packaged to be unhelpful and really inferior. If one is packaging a new version that really has no Debian-related changes or which is just fixing minor bugs or adding minor new features, none of which of interest to the average user, a bare "New upstream release" makes sense. But I prefer to provide at least a line or two of detail, and as long as one doesn't overdo it, there isn't much drawback. A pure "no upstream changes should be in the Debian changelog file" policy would break down in a number of places. Some upstream changes I think everyone agrees should be listed there (such as CAN numbers for fixed security bugs). Note: I use apt-listchanges and read the changelog deltas for every package I upgrade on four different machines, so I am one of the people who has to page through lengthy changelogs. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]