migration project

Meeting notes


Whilst the overall Ailoth deprecation plan assumes that the existing mailman installation will not be migrated, there are in fact tentative plans from a separate group of Debian members to migrate at least some of the mailing lists on the current installation to a separate, unofficial system hosted under for a time limited period of a few years (1-2 release cycles).


Whilst many of the functions of the alioth list server can be readily transferred elsewhere (eg discussion lists on, or commit notification lists integrated with gitlab) around 50% of all packages in the archive use alioth mailing lists in the Maintainer field and are thus the primary contact point for the BTS and other contact with package maintainers. Whilst there are discussions on how to replace this need, we do not believe the upload of half of Debian to replace the Maintainer field will be practical (particularly for teams with many thousands of packages). This migration project will therefore allow continued these package maintainers to continue to receive bug reports and other emails for their packages during this transition.


The following individuals are working on this project:


This project is still in the stage of assessing viability and gaining the necessary buy-in from key Debian project members. It seems likely that DSA will be willing to set up the required http redirection and MX records based on current responses from members.


The project would need to be completed by the time the existing alioth infrastructure is shut down, which at the last announcement was 1st February 2018.

Architecture and infrastructure

The planned approach is to set up a virtual machine provided by Dominic Hargreaves hosting an instance of Mailman 2 and the necessary front-end services (Apache, Exim et al). Administrative access would be made available to selected Debian Developers (TBD) so that the administrative burden on individuals was not excessive.

Existing front-end mail exchangers already exist with spamassassin and clamav filtering, which would be the least up-front work; alternatively these services could be deployed inside the VM which would enable them to be managed by the team.


Migrating all lists is the simplest possible approach but it was noted that many lists are unused and/or their archives are full of spam, so my preferred approach currently is to ask each list owner to opt-in to migration. This will also reduce the disk space requirements to more manageable levels.

This will also allow us to seek explicit permission to copy data from the current alioth to the less-official new one.

On the other hand, all lists (around 300 according to alexm) listed in Maintainer fields in sid should also be included by default.

It has yet to be determined the exact method for migrating data; this needs further discussion with the alioth admin team.