Date: Tue, 28 Apr 2020 17:33:41 +0200 From: Matthias Andree <matthias.andree@gmx.de> To: Kurt Jaeger <pi@freebsd.org>, Dan Langille <dan@langille.org> Cc: FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: mail/mailman v3? Message-ID: <8684b670-d968-7457-231e-720ab8449190@gmx.de> In-Reply-To: <20200424130424.GJ39563@home.opsec.eu> References: <FD5DA99A-4B99-4730-BD8E-7079416A56BB@langille.org> <20200424130424.GJ39563@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
[Dan, Kurt, this is a re-send of my message written 2020-04-24 with a different sender address.] Am 24.04.20 um 15:04 schrieb Kurt Jaeger: > Hi! > >> With mail/mailman being Python 2.7 (which is end-of-life), and mailman = 3 being Python 3 compatible: >> >> Do you know of any plans to port Mailman 3? > > There's already a PR about that: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225543 > > The patch itself is fine, but we need run-tests. > > This means: If you want to help, > - use that patch, > - build mailman3, > - and install it somewhere and > - test all the use-cases that you can think of > - then write some docs on how to move an existing mailman2 site > to mailman3 > - and give ideas how to handle list archives > *especially* keeping the URLs identical (!) > > And, speaking as one of the postmaster@ team: > As lists.freebsd.org uses mailman2, we need this! > > postmaster@ has not yet decided if we really want to move to mailman3, > so we are open to other options. The mail archive is the biggest hurdle = 8-( > Thanks Dan for the question, and Kurt for answering that question. As the mailman2 maintainer frequently being asked about mailman3, here are my thoughts on it. TL;DR: mailman3 documentation is an untidy inconsistent mess, is in my perception not honestly and outright advertising the mailman 2.x features that have not yet been reimplemented. The minimum version to be ported should be the latest release as they are still re-adding lost features, for instance, 3.3.1 is current has brought bounce processing. I am not driving mailman3 efforts, don't want be in the first line or maintain a mailman 3.x port, but may help here or there if I am being asked on advice. Long version: I have looked at Mailman 3 again and again, and the more often I look, the more I balk at it. Mailman 3 will be five years old coming Tuesday (3.0.0 released 2015-04-28), and the first-hand documentation is scattered across web sites and inconsistent, not frequently updated for the new releases. Mailman 3 is also a new product, "Mailman 3 is a fully rewritten code base." <https://mailman.readthedocs.io/en/latest/src/mailman/docs/release-notes.h= tml>. It could bear a new name in honesty, and more importantly that means all the workarounds and experience from 2.x are lost, and have to be re-written, too. And some have not been, and they admit it on the hind pages. - FEATURE ADVERTISING COMPLETENESS: In quality and features 3.x appears to boast new "features" over 2.x but does not in the same prominent place list what's missing. Most of the "features" are implementation details that I don't deem critical for day-to-day operation. Others were just added less than a week ago, f.i. bounce processing only arrived in 3.3.1 - and the web sites above advertising feature advances over 2.x are at 3.3.0 or older status and DO NOT MENTION bounce processing missing, so the only conclusion is that there are more 2.x features missing in 3.x without being prominently marked as such. Quoting NEWS.rst > Features > -------- > * Add support for processing of email bounce events. Thanks to Aaryan Bh= agat for > working on this as a part of his GSoC project and Thanks to Google for > sponsoring the project as a part of GSoC.(See !584) Look right ABOVE the 3.3.0 section. <https://gitlab.com/mailman/mailman/-/raw/master/src/mailman/docs/NEWS.rst= ?inline=3Dfalse> (gitlab cannot render it with decoration, this is a download link instead, some 80 kB) - MIGRATION: http://docs.list.org/en/latest/migration.html mentions breaking archive URLs, and also "Some configuration and settings aren=E2=80=99t available i= n Mailman 3=E2=80=99s UI yet, so even though those settings will be migrated= to Mailman 3, you may not be able to change them from the Web UI today. All of those settings should be exposed in the UI very soon. Mailman 3 doesn=E2=80=99t have support for bounce processing yet, but it i= s on the roadmap." - so obviously the migration guide is outdated, too. - DOCUMENTATION TIDINESS: Mailman 3 documentation and everything is scattered across what feels half a dozen places, all inconsistent WRT what is the current version, features and all that, and obviously not kept up to date with releases. - https://mailman.readthedocs.io/ - https://docs.mailman3.org/en/latest/ (not sure how that relates to readthedocs, may be an alias or a copy) - https://wiki.list.org/Mailman3 - http://www.list.org/ - https://gitlab.com/mailman - https://pypi.org/project/mailman/ which seems to be the most up to date download - DEVELOPMENT AND COMPONENT CONCISENESS The Gitlab site show many side projects with unclear relation to the "mailman suite", no easily accessible roadmap besides a five-or-six-item list of what makes up the suite. Given the shape of the documents, and even assuming that documentation is the first thing that falls short in commercial time-pressed development, I find that messy. There is certainly a LOT of work to do, work out processes to get documentation consistent with the code releases, then actually do that. - PERSONAL CONCLUSION AND OUTLOOK This is a subjective and personal note of someone who has not read a single line of Mailman 3 implementation, but only its documentation that's accessible from web sites and several one-or-two clicks deep hyperlink chains, but is asked again and again (as mailman 2 maintainer) about mailman 3. I have shown how I feel that the documentation is untidy, inconsistent, and partially unmaintained on sites that are linked from list.org. I have shown how I personally do not trust that mailman 3 is feature-complete when looking at the mailman 2.x feature set. So assuming we've had a port, what calms a potential porter's or maintainer's mind that he's not going to be drowned in user support? Personlly I fear that a port would bring with it lots of people getting tripped up by the inconsistent web sites, and it would probably add more support work than the sum of all other ports I am currently listed MAINTAINER for. So I don't want to play a *major* role in the porting, feel free to ask me here or there, and I will not become maintainer now. If Python 3.x were not a rather important argument, I would have written a polite form of "leave me alone with that immature stuff and would have moved on. - FINAL QUESTIONS Leaving Python 3.x compatibility aside, what good arguments can anyone weigh in for Mailman 3.x who is using it in practice (f.i. on Linux)? How is it better? Is it mature? Would it be plausible to port Tauthon 2.8.2 (I am not doing that) and continue using mailman2 on it (I might help with this part)? <https://github.com/naftaliharris/tauthon>;
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8684b670-d968-7457-231e-720ab8449190>