Mailinglists for collaborative maintenance

The following thoughts were exchanged during the Alioth Sprint 2017.

Discussion summary

Possible manual migration of Alioth mailing lists to lists.d.o

Listmasters are willing to have some more lists on, but not all that are currently on alioth.

Lists may be granted on request based on the following requirements:

New lists will have common list settings - open list, free subscription, open archives.

Every list owner needs to request a list manually. There will be no automatic migration.

We prepared a minimal export script for retrieving the mailing list archive and the subscriber list from alioth. These can be imported by the listmasters.

Migration tasks

Howto proposals

Migrate mailinglists from alioth

Recipients of the following text: * alioth accounts with project admin rights * mailing lists owners (yes, they might be different and the latter not aware of alioth at all)

The lists eligible for migration must follow the requirements outlined on the "How to ask a mailing list" guide ( The process is also the same as outlined on the guide.

That is to say, the list is expected to be useful, to have a purpose and an audience. A public discussion or support list is probably OK, but commits or bug notifications should use the dedicated features of gitlab instead, and if you're interested in a package's bug, you're expected to subscribe to it using the BTS features.

Short version: file a bug on the pseudo-package with the severity 'wishlist', with the following information:

Lists migrated from Alioth are expected to be open, that is:

If you do want the archive and/or the subscribers to be imported into your new mailing list, please:

Also, please understand that the requirements and features for lists on are not the same as for a mailing list on Alioth, and the listmaster might reject your request. cannot replace all mailing lists and aliases on Alioth.