[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libgtk2.0-0: changelog.Debian.gz is not an upstream changelog



Christian Marillat <marillat@debian.org> 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 (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: