mailman: document OOM issues and mailman alternatives (#41957) authored by anarcat's avatar anarcat
......@@ -870,6 +870,9 @@ label ~Lists.
- Templates cannot be edited from the web interface, see [#41855](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41855)
- [Cannot disable signups on lists](https://gitlab.com/mailman/mailman/-/issues/1088)
- [Xapian search engine uses up too much disk space](https://gitlab.com/mailman/hyperkitty/-/issues/533)
- [Mailman runs out of memory](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41957), mitigated by the switch to Xapian
which brought this from dozens of times per week to a couple times
per week
## Maintainer
......@@ -1003,7 +1006,76 @@ on [PostgreSQL](howto/postgresql) recovery.
## Other alternatives
<!-- include benchmarks and procedure if relevant -->
### Discourse
When the [forum service](service/forum) became self-hosted, it was briefly
considered to retire Mailman 2 to replace it with the Discourse
forum. In [may 2022](meeting/2022-05-09#bullseye-upgrade-phase-3 ), it was noted in a meeting:
> We don't hear a lot of enthusiasm around migrating from Mailman to
> Discourse at this point. We will therefore upgrade from Mailman 2 to
> Mailman 3, instead of migrating everything to Discourse.
But that was before we self-hosted Discourse:
> As an aside, anarcat would rather avoid self-hosting Discourse unless
> it allows us to replace another service, as Discourse is a complex
> piece of software that would take a lot of work to maintain (just like
> Mailman 3). There are currently no plans to self-host discourse inside
> TPA.
Eventually, the [2022 roadmap](roadmap/2022) planned to "Upgrade to Mailman 3 or
retire it in favor of Discourse". The idea of replacing Mailman with
Discourse was also brought up in [TPA-RFC-31](policy/tpa-rfc-31-outsource-email) and adopted as part
of the [TPA-RFC-20 bullseye upgrade proposal](policy/tpa-rfc-20-bullseye-upgrades).
That plan ended up being blocked by the Board, who refused to use
Discourse for their internal communications, so it was never formally
proposed for wider adoption.
### Keeping Mailman 2
Besiids upgrading to Mailman 3, it might have been possible to keep
Mailman 2 around indefinetly, by running it inside a container or
switching to a [Python 3 port of Mailman 2](https://github.com/jaredmauch/mailman2-python3).
The problem with running an old container is that it hides technical
debt: the old, unsupported and unmaintained operating system (Debian
11 bullseye) and Python version (2.7) are still there underneath, and
not covered by security updates. Although there *is* a fork of Python
2 ([tauthon](https://github.com/naftaliharris/tauthon)) attempting to cover for that as well, it is not
considered sufficiently maintained or mature for our needs in the long
run,.
The Python 3 port of Mailman 2 status is unclear. As of this writing,
the README file hasn't been updated to explain what the fork is, what
its aims are or even that it supports Python 3 at all, so it's unclear
how functional it is, or even if it will ever be packaged in Debian.
It therefore seemed impossible to maintain a Mailman 2 in the long
run.
### Other mailing list software
- [sympa](https://www.sympa.community/) is the software used by Riseup, about which they have
mixed feelings. it's a similarly old (Perl) codebase that we don't
feel confident in.
- [mlmmj](https://mlmmj.org/) is used by Gentoo, kernel.org, proxmox and others as a
mailing list software, but it seems to handle archiving poorly, to
an extent that people use other tools, generally [public-inbox](https://public-inbox.org/README)
([Gentoo](https://public-inbox.gentoo.org/), [kernel.org](https://lore.kernel.org/)) to provide web archives, an NNTP
gateway and git support. mlmmj is written in C, Perl, and PHP, which
does not inspire confidence either.
- [smartlist](https://zhilianghu.github.io/SmartList/) is used by Debian.org and a lot of customization,
probably not usable publicly
If mailing list archives are still an issue (see
[tpo/tpa/team#41957][]), we might want to consider switching mailing
list archives from Hyperkitty to public-inbox, although we should
consider a mechanism for private archives, which might not be well
supported in public-inbox.
[tpo/tpa/team#41957]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/41957
## Mailman 2 migration
......
......