Hi!
On Tue, 2019-12-03 at 08:15:19 +0100, Paolo Greppi wrote:
> What is the best approach for d/changelog when releasing a package
> to unstable after it has been through a few iterations to experimental ?
>
> It would seem that the right thing to do is to keep all experimental
> changelog entries, and add a new one for unstable.
That really depends on how one manages these branches and uploads.
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.
> But sometimes experimental uploads are, well ... experimental, there
> may be changes that cancel out (I tried this but it did not work, then
> I tried that etc.).
> So another way is to consolidate all experimental changelog entries
> into the unstable one, tidying it up.
> Also as most people never see the experimental releases, they only
> care for what's new since the last release to unstable / stable.
I think the two main ways to handle these are either based on
something ressembling the shape of «git cherry-pick» or «git merge».
* For a «git cherry-pick» kind of approach, an upload to experimental
does not imply that the changes there should or might end up all in
unstable, it might end up being, say, a dead-end diverging VCS branch,
and you could simply backport the various atomic changes in atomic
squashed logical units into unstable to drop any intermediate
changes/commits.
Or another similar approach might keep them in sync, by doing the same
packaging changes to both the unstable and experimental branches, and
upload both at around the same time. Then you could eventually just
upload the package from experimental into unstable. You'd lose upload
information, but not change information. The former can easily happen
within stable vs testing/unstable anyway, or with not ACKed NMUs for
example, so I don't think it's a big deal, and the upload information
is anyway tracked in DAK or tracker.d.o.
* For a «git merge» kind of approach, then what can happen is that
you've got changes reverted in one place and reintroduced in another,
so how you sort the entries in debian/changelog is even more important
to avoid confusing people reading the entries. In this case, if using
version-sorted entries, it can make them stop making sense, and
date-sorting would confuse automated parsing, neither of these would
really represent the actual timeline of the changes, so I'd recommend
injecting the entries as sub entries. So as an example, it could look
something like this:
,---
pkg (1.0.0-11) unstable; urgency=medium
* Enable feature foo.
-- Name <email> Date N + 6
pkg (1.0.0-10) unstable; urgency=medium
* Merge from experimental:
pkg (2.0.0-5) experimental; urgency=medium
* Disable feature foo.
* Some other change Z.
-- Name <email> Date N + 3
pkg (2.0.0-4) experimental; urgency=medium
* Enable feature foo.
* Some other change Y.
-- Name <email> Date N + 1
* Some other change B.
-- Name <email> Date N + 5
pkg (1.0.0-9) unstable; urgency=medium
* Some other change A.
-- Name <email> Date N + 2
pkg (1.0.0-8) unstable; urgency=medium
* Disable feature foo.
-- Name <email> Date N + 0
`---
Of course if “Enable feature foo” would have happened already in
1.0.0-9, then that'd be reather confusing, but would imply a mix
of different merge strategies. :)
Thanks,
Guillem
