mail/mailman v3?

Tue Apr 28 20:02:05 UTC 2020

On Tue, 28 Apr 2020 17:33:41 +0200 Matthias Andree matthias.andree at gmx.de said

> [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=225543
> >
> > 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.html>.
> 
> 
> 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 Bhagat
> > 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=false>
> (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’t available in
> Mailman 3’s 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’t have support for bounce processing yet, but it is 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>

In sentiment I am inline with your thoughts as well.
Would it be a worthy project to create a mailman(2)-lts port?
I'd be fully up for helping, and or creating it myself.
There's a port that's a shim for py2.x-->py3.x called 2to3, or something
like that. It also wouldn't be that difficult to simply modify mailman(2)
to adopt the py3.x language changes.

My 3¢ for what they're worth. :)

--Chris