Overall I think it is usually best to include the changelog entries
for experimental versions in the appropriate place in the changelog
for the sid upload, unless they really contain only stuff that was
later undone. That is helpful for humans and also for computers.
For example, consider what ought to be shown by apt-listchanges
(which shows you the top part of the changelog since the version being
upgraded from).
Simon Richter writes ("Re: d/changelog and experimental"):
> Bugs are closed based on the changes file, which is generated from the
> topmost entry, always.
This is not strictly speaking correct.
If the most recent upload to sid (say) is not the second-topmost
entry in the changes file, then the .changes for the sid upload
should contain *all* the entries since the last upload to sid.
This can arise in situations other than where the intervening versions
were upload to experimental. Perhaps the intervening versions were
not uploaded at all, or were REJECTed, or were uploaded to another
distro. [1] In those situations the intervening bug close entries
need to be processed.
You can get this right by passing a -v option to dpkg-genchanges via
the appropriate mechanism for your usual build and upload tools.
Or you can just use dgit which gets this right automatically :-).
Ian.
[1] A workflow is possible where you use one git branch and just add a
new changelog entry for each upload. Although our data formats would
support uploads to a multiple distros with a single changelog entry
and even a single signed .changes, unfortunately our various tools and
services don't. But writing an additional changelog is easy.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
