[Mailman-Users] The last release from the GNU Mailman project

[Stephen J. Turnbull]

Brian Carpenter writes:

 > I have hired a professional PHP developer to begin work on a new 
 > admin/forum interface for Mailman 3.

Too bad.  I really sympathize with your goals but am unlikely to be
able to contribute directly to implementation (assuming an eventual
open-sourcing).  Never learned PHP, not going to do it anytime soon.
That's OK, the point of REST is so *you* *can* do that.  I can only
speak for myself, but we can help to some extent on the Python side of
the REST interface.

A word of advice: we, too, talked about "modern forum software and
interfaces that users expect", but implementing them well is a lot
harder than we expected.  I'm not saying it's too hard for your
developer, but stay on top of that project!  Mail is hard to combine
with forums, and it's easy to stray into the weeds.

 > 2. Mailman 2 does need to be ported to python 3 eventually

Sure, but that's still quite a ways away.  The main issues I can see
would be related to TLS, where old versions of the protocol seem to be
deprecated more and more rapidly, but it's probably easier to patch
Python 2 for that than to port Mailman 2 to Python 3.  Sure, there may
be non-TLS CVEs against Python 2, but I really can't see them being as
serious as the kinds of issues that Mailman 2 itself, not to mention
any site with mail service, would have.

 > 3. The decision to use Django. Maybe great for Python users

This makes no sense to me.  If your problem with Django is that it's
written in Python, you've got the REST interface.  That's as far as
our responsibility goes.  See "REST is the approach" below.

 > 4. [W]ay too many methods of installing it which means all kinds of
 > versions of Mailman 3 are in production today because Mailman
 > versions are dependent upon what method of installation a person
 > chooses: Distro Package, Docker, Source, others?

That's not a problem we created.  Our recommendation is, as it always
has been, build from source.  And the problem is not going to go away.
Users want turnkey packages such as containers, distros can't be
stopped from building distro packages.  If you open source your
interfaces, you'll run into the same issues.

 > I think the highest priority is to get Mailman 3 core up to speed
 > in offering everything that Mailman 2 offers such as bounce
 > processing.

Agreed.  I didn't even know bounce processing wasn't working until
this summer (my production lists are all in-house to personal
acquaintances to same-university addresses -- if mail isn't flowing to
somebody, it's not going to anybody, even Mailman!)

 > Then perhaps a whole new approach to interfacing with Mailman 3
 > core is in order.

REST *is* the "Mailman 3 approach" to interfacing.  Historically, at
the time Mailman 3 core got whipped into shape to start beta testing,
we went with Django for Postorius, because it was the "hot" framework
of the day, and that's what the developers who volunteered wanted to
work with.  Of course it had to be a Python framework since we'd be
maintaining it.  HyperKitty was a little bit different: the Fedora (or
Red Hat?) people wanted Mailman 3 for internal reasons, and they
contributed a pile of labor, and (AFAIK) independently chose Django
and developed the UI based on it (which is why we have two separate
Django configs).

*However*, the original idea was that *we* didn't know much about UI
development, especially the peripheral features of archiving such as
search and access control, and we wanted to encourage third parties to
develop their own, or to integrate Mailman lists into their larger
platforms which already provided user interfaces.

 > I hope I did not offend anyone here

The main Postorius devs aren't hanging out here, and we get only a
little contact in the summer with the HyperKitty devs since the Fedora
support got cut three or four years ago. ;-)  If I know Mark he
started a little miffed but calmed down quickly since diverse UIs have
always been part of the vision.

 > I would be interested to know if the developers of Mailman 3 are
 > interested in the initiative I have taken to develop new interfaces
 > for Mailman 3

As far as I know this is precisely what we wanted to happen in the
first place.  We knew that we would have to have a bundlable
user/admin interface and an archiver with a web interface, but the
original intent was not that they dominate Mailman installations.  We
should have known better, given the huge popularity of Mailman 2 with
Pipermail (oh, Lordy) as the archiver, but hope springs eternal ....

I think further discussion should move to mailman-developers, though,
and please introduce your UI developer(s) to us on mailman-developers
soonish.  Nobody has huge amounts of time to put into work on Mailman
right now AFAIK, but I expect we will be willing to cooperate on any
Mailman features or fixes your developer needs in the REST interface
"in good time".

I'm going to be very busy until March 11, but after that I'll have
some time.  Ginning up a list of REST endpoints is the kind of thing
I'm good at, so maybe I personally could start there.

Steve