Note: This was done, and is preserved for historical purposes.
Alioth is shutting down. Several of the services that dpkg uses need to be migrated elsewhere. This page covers what those are and the alternatives, with possible pros and cons.
Services used from Alioth
- git repos: anonscm.debian.org
- hook: debbugs tagpending
- git.dpkg.org: git-tag-pending hook.
- salsa.d.o: webhook available.
- hook: commit email notifications
- git.dpkg.org: git-multimail hook.
salsa.d.o: support email notifications but it sends all commits in a single mail, and this is apparently not going to be fixed in salsa. Upstream bug.
- hook: IRC notifications
- git.dpkg.org: kgb-client hook.
salsa.d.o: support for KGB (https://salsa.debian.org/kgb-team/kgb/wikis/usage, but it uses URL shorteners 900706) or irker instances.
- hook: CI trigger
- git.dpkg.org: grml-jenkins trigger hook.
- salsa.d.o: runners now available.
- salsa.d.o: there are a couple of plugins for jenkins and gitlab.
- group commit rights (although might want to consider settting up the repos in a different way to avoid push+release clashes)
- git.dpkg.org: a couple of push only SSH accounts can be easily created.
- salsa.d.o: supported by default.
- hook: debbugs tagpending
- static website: www.dpkg.org → dpkg.alioth.debian.org
- git stats
- www.dpkg.org: gitstats trigger hook.
- salsa.d.o: can be replaced with the built-in support.
- historic VCS and release tarballs
- www.dpkg.org: easy hosting of the few files, TLS support.
- salsa.d.o: pages support, not sure whether it's a good fit for biggish content. Does not look likely.
- libdpkg doxygen generated docs
- www.dpkg.org: trigger hook.
- salsa.d.o: pages support, could be generated manually (like now) or could be triggered as part of some CI/CD setup.
- code coverage reports
- www.dpkg.org: trigger hook.
- salsa.d.o: pages support, could be generated manually (like now) or could be triggered as part of some CI/CD setup.
- git stats
Alternatives
salsa.debian.org
Option rejected
This is the natural successor. Although it currently poses some problems, many are probably fixable, others are minor paper-cuts.
Cons:
- URL-change-fatigue and service-tied URL. Ideally the URL should be service neutral, like the previous anonscm.d.o.
- there's now a redirector in place, but it specifies the redirection as permanent, which makes git emit warnings, and it states it should be immediately reverted once the repos have been migrated.
- some of the webhooks are currently suboptimal or plain broken.
- single notification mail for all commits.
- KGB uses shortened URLs.
- gitlab seems to have a somewhat broken web notification system (paper-cut).
- the current setup makes everyone be a member of the collective debian group which means every and each project there is your own, and there's no obvious way to pin specific repos.
- namespaces is already a mess.
Pros:
- "obvious" migration path, supported by Debian.
- out-of-the-box groups/users/maintenance.
- provides very interesting features: merge requests, built-in CI, etc.
- pages support.
(git|www).dpkg.org
Option accepted
Cons:
- self-hosted (DSA do not seem happy to host any of this themselves).
- possibly annoying or no user-management, but it should really require just a couple of accounts in any case.
Pros:
- way more stable URLs, and can host redirectors in "perpetuity".
- can automatically push to the various hosting instances easily with access tokens or similar (salsa, github, etc).
- can easily host the web site.
- can easily trigger CI/CD on the same system.
- can use whatever hooks we want (including non-limited KGB or broken email notifications).
dpkg.debian.net
Option rejected
Similar Cons and Pros to using dpkg.org. And in addition:
Cons:
way way worse URLs, no distinction between www and git URLs.
Pros:
- does not require approval from anyone.
- even if we get better URLs later on, they can be cheaply redirected in "perpetuity".
