[Mailman-Users] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

Jim Popovitch jimpop at domainmail.org
Mon Mar 2 16:55:40 EST 2020

On Mon, 2020-03-02 at 10:54 -0800, Mark Sapiro wrote:
> On 3/2/20 8:56 AM, Jim Popovitch via Mailman-Users wrote:
> > Barry's roadmap
> > for Python2 -> Python3 seems to counter the narrative that MM2 is ill-
> > advised to be ported to Python3 (btw, that was posted in Jan of this
> > year).
> The question is what do people want when they say they want Mailman 2
> ported to Python 3.

I believe they want Mailman 2, as it is today, but with a fully
supported language that it depends on.  Lets be clear, the upgrade from
MM2 to MM3 is not the same as a traditional upgrade path, MM3 is a whole
new application.  It's an application upgrade the same way the Space
Shuttle was an upgrade from the Apollo capsules.  Different designs,
whole new concepts, years of pie-in-the-sky and dry marker dust.  While
that is important to some, it may not matter to others (and I think that
is the situation today).  I really want to know who all the "we need a
REST interface now!" people are.

I'm reminded of that great diagram from years past about "what the
customer wanted", "what the developer envisioned", "what the tester
tested", etc.  It's a great reminder of how quagmires are created.

> If it means, porting to Python 3 and fixing a few things on the way such
> as adding a real backend database, a concept of "user" and a REST API,
> it's at least partially done. It's Mailman 3 core.
> If it means cloning the MM 2.1 web UI and pipermail archiver, that is
> almost certainly not worth the effort.

There are plenty of people who are still happy with pipermail and some
of the other search options (Google, htdig, etc)  What benefit does a
REST api provide to church groups, and tech lists like nanog or mailop? 

BTW, I've run some technical discussion lists for 2 decades now, I can
recall the number of times someone has said "we need an archive search
feature" on 1 hand.
> A compromise is exactly what Brian proposes. Mailman 3 with a new web
> UI, light weight, not based on Django and easy to install. Mailman 3 was
> explicitly designed to be separate from a web management UI and Archiver
> and to allow different implementations of those to integrate easily with
> core.

While I applaud Brian's efforts, I'm not convinced that I would run PHP
on a public facing portal, even in 2020.  But that's just me, others may
feel differently.

> Postorius and HyperKitty are part of Mailman 3 because we needed
> something and that is what people were willing to commit to do. We
> always hoped there would be alternatives, and it seems that now Brian is
> working on one. There's room for more.

-Jim P.

More information about the Mailman-Users mailing list