Hi, On 08.12.19 22:29, Guillem Jover wrote: > I think there are two important properties that need to be preserved > so that debian/changelog entries keep making sense both for humans > and machines alike. The first is that the parseable format entries > should be sorted by version, otherwise things that parse the file > might get confused when doing range checks or filtering things. The > second is to preserve the timeline of the changes, so that when a > human (or even a parser that extracts semantic meaning like with bug > closures) reads them they should still makes sense. For backports, we already have cases where entries aren't sorted, because the changelog still lists the version from sid, and the entry for the backports version is then prepended with a lower version number. Bugs are closed based on the changes file, which is generated from the topmost entry, always. The rest of the changelog only exists to preserve history. When you make an upload to experimental closing a bug, and you later upload the package to unstable, you have to close the bugs again in the changelog entry for unstable. At this point, it makes sense to condense the changelog to things that have actually changed. The target audience of the Debian changelog is a skilled system administrator who wants to know what changes in behavior to expect from the new version, especially deviations from what is described in upstream documentation (because Debian applied a patch). The format is too terse to serve as a full history of the package itself, it can only provide pointers to more documentation, ideally inside the BTS so it is archived within Debian and crosslinked. The example you give for a merged changelog is confusing, and there is no way to make it less so save for a dedicated tool to visualize it -- but such a tool could also access the git history of the package instead. Simon
Attachment:
signature.asc
Description: OpenPGP digital signature