Transitions

The usual workflow - quick guide

This section covers the most common ABI/API transitions. Most items also apply to other transitions. The Release Team considers everything a transition where the upload of a package requires changes (rebuilds or actual patches) to reverse dependencies.

Applies to

The work flow

The Request

Please request a transition slot from the Release Team by filing a transition bug report against release.debian.org (reportbug has a template). In some cases (major transitions), it might be prudent to also send an email to debian-devel-announce, but please see the section below on that subject.

In the transition bug report, please include the list of affected source packages and what needs to be done with each of them. In some cases, a lot of binNMUs will be enough (e.g. a clean library ABI bump) though in other cases sourceful uploads are required (e.g. API change).

Please do not upload the package to unstable without approval from the release team.

debian-devel-announce mails

If you are sending an email to d-d-a about the transition, here are some recommendations.

Speeding up transitions

Here are some hints to getting your transitions started and finished sooner.

How transitions work in general

For the interested, this is the extended general work flow for most transitions. It includes actions from all involved parties.

In the following, the following legend is used:

The general work flow is something like this.

  1. [MTL]: Uploads to experimental, which will generally end up in NEW
  2. [FTP]: Approves upload to experimental.
  3. [AUTO]: The "auto-transitioner" usually detects the planned transition and generates a tracker at https://release.debian.org/transitions/ (under "Some planned transitions")

  4. [MTL]/[MRD]: Test build the reverse dependencies against the new ABI/API.
  5. [MTL]: Files a bug against release.debian.org requesting a transition slot with the affected reverse dependencies and the test results.
  6. [RT]: Reviews the request and decides an appropriate time for the transition. Usually defined as "now" or "after the current transition(s) X(, Y and Z)".
  7. [RT]: Acks the transition, usually with a human readable confirmation.1

  8. [MTL]: Uploads library to unstable.
    • MILESTONE: The transition is started and can become entangled.
  9. [MTL]: Bumps all blocking bugs to RC.
  10. Interleaved (repeated until all reverse dependencies are updated on all architectures in testing):
    • [RT]: Schedules binNMUs for reverse dependencies that just need a rebuild
    • [MRD]/[MTL]: Uploads reverse dependencies that needs to be updated for the new library version
    • [AUTO]: The automatic removal from testing may remove some of the unfixed packages from testing.
  11. [FTP]/[AUTO]: The FTP masters or DAK's auto-decrufter will remove the old ABI/API package in unstable.
    • This is automated if all reverse dependencies are successfully updated (or removed)
    • This is manual if there are problems on some architectures outside testing
  12. [AUTO]: Britney will migrate the new library package. With smooth updates, the old library ABI may be retained in testing.
    • MILESTONE: At this point, the transition will generally no longer become entangled with others.
    • Without smooth updates, Britney will have to migrate all of the reverse dependencies at the same time.
  13. [AUTO]: Britney will migrate all reverse dependencies as they become ready.
  14. [AUTO]: Britney will remove the old library if it is still present in testing.
    • MILESTONE: The transition is now complete.
  15. [RT]: Closes the release.debian.org bug.
  1. The release team tracks the ACK for a transition using the 'confirmed' tag in the BTS. (1)