Re: d/changelog and experimental

[Guillem Jover <guillem@debian.org>]

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