Dependencies on alioth services

Things that will break when alioth.debian.org is shut down.

Git

pkg-perl most used service in alioth is git, plus remote hooks that send notificacions to PET, IRC and lists, and another hook that builds the HTML web pages from POD files in website repo.

Status

Hooks

The admins of Salsa are reluctant to run user code on the server. Alternatives on gitlab are Webhooks and CI runners (at list for Web pages).

repository management

repository creation scripts will have to be (re)written to use gitlab API

KGB

KGB instances run on dmn's, gregoa's and Tincho's servers. The client is an Alioth, triggered by our hook script.

Status

This will need replacement.

Since a hook script is probably not possible, we have to rely on Webhooks (unless the Salsa admin are willing to setup a CI runner for this).

Gitlab's Webhook are fixed, so it would mean specific support on KGB side (looks feasible) or switching to another bot.

Alternatively (or in the meantime) jenkins.d.o uses a mail to KGB script called from procmailrc. It's not a very clean solution but it might be an acceptable temporary one, maybe rewriting the script for better mail parsing (i.e. not in shell), like suggested in the latest versions

PET

PET runs on petrova.debian.org, so it's not an alioth service though it may depend on some alioth magic like repos traversal, running local scripts, etc. that send changes to PET, triggered by our hook script (and a cronjob with "update-all" just to make sure).

Status

This will need replacement. We need to see what exactly is done on Alioth to find alternatives.

.mrconfig and repo management scripts

Additionally, our fancy .mrconfig piggy-backs on PET's cache file (to `git pull' only from repos where the local last commit differs).

And .mrconfig itself is updated by dpt-alioth-repo (locally) and by a bunch of scripts on alioth for adding/archiving/removing git repos.

Tagging bugs pending also happens from the hook.

/home/groups/pkg-perl/meta/pkg-perl-post-receive

Status

This will need replacement.

Mailman

Both pkg-perl lists (pkg-perl-maintainers and pkg-cvs-commits) are used mostly for notifications (VCS, bts, etc.) so they don't match the criteria for migrating them to l.d.o. In the case of pkg-perl-maintainers, we'll need to come up with some solution since it's the contact in Maintainer field in d/control for all 3400+ packages maintained by pkg-perl team.

58% of all archive packages have @lists.alioth.debian.org in Maintainer field

Status

This is still in discussion. Someone might provide a replacement for list, and there will probably be some kind of redirection available.

Calendar

The pkg-perl calendar file in website repo is built manually by dmn.

A static file, manually curated in git and exposed via the webspace

Status

It should be easy to set up via Gitlab Pages on Salsa.

Annual ping reminder

The annual ping reminder for pkg-perl members is run in alioth via pkg-ruby-extras' find-inactive-contributors, plus some additional steps for pkg-perl.

Status

This will need replacement.

Sphinx

There's a proof of concept pkg-perl manual in the website repo that is build from POD files via Sphinx and then rsync-ed to alioth manually.

Status

This should be easy to reproduce with Git pages (actually, the pkg-perl web pages were used to test the Gitlab Pages during the sprint). We might even have Sphinx available on Salsa to build the pages directly in Gitlab (if it's worth building on every push).

QA

There are also scripts/cronjobs to produce the 2 files in https://pkg-perl.alioth.debian.org/qa/

Status

This will need replacement, and won't run on Salsa.

Other services

LHF reminder

The LHF reminder uses https://anonscm.debian.org/cgit/pkg-perl/scripts.git/tree/lhf-reminder and is run by dom

perl.debian.net

Server runs on Dom's hardware. ntyni also has access.

CI coverage

script to post "CI coverage" notices daily on IRC: run by dam somewhere.