List of dependencies to backport

git diff between last version in fasttrack and current master HEAD of debian/control can be used to find the dependencies that needs backport when updating gitlab to a newer version.

Example git diff debian/12.2.9-5..HEAD debian/control

From the diff, update the task tracker (For example, https://git.fosscommunity.in/debian-ruby/TaskTracker/issues/151) with a todo list.

How to backport a dependency

Add your name next to a package to backport to reserve it (to avoid duplication).

The steps to backport a dependency is documented in salsa wiki

Where to upload a dependency

  1. If a dependency satisfies the requirements/criteria for official backports (already in testing), then it should be uploaded to official backports.
  2. If that package needs to clear backports-new, then it can be also uploaded to fasttrack/buster-backports temporarily, to avoid waiting. Once the package is accepted into official backports, it should be removed from fasttrack.
  3. If a package is not in testing (blocked by transition or freeze), it could be uploaded to fasttrack/buster-backports .
  4. If a package is in NEW for a long time or needed for a security fix, it can also be uploaded to fasttrack/buster-backports.

  5. A package should be uploaded to buster-fasttrack only in case the package cannot be in testing permanently due to short release cycle or the package maintainers are opposed to maintaining it in backports (for example ruby interpreter). All native ruby libraries that depends on the version of ruby should be in fasttrack and any pure ruby library that depends on the native library can also be in fasttrack. Build dependency on gem2deb should be >= 1.3+ to force building with ruby 2.7.

If a package dependency is not yet in stable/backports

  1. Backport the dependency.
  2. Build the current package by passing the dependency in --extra-package option.
  3. The package and all the (build) dependencies which are not in stable/backports should be uploaded to backports.