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

[Jim Popovitch]

On Fri, 2020-02-28 at 19:52 +0900, Stephen J. Turnbull wrote:
> 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.

Stephen, It's difficult for me to parse your thought process on this.
Why do you say "Too bad" about someone wanting to improve something that
you admit you want no part of?

> 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.

Who is this "we", you referenced them a few times in this email.


>  > 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.

I'm fairly confident in saying that Mark has said (repeatedly now) that
there will never ever ever ever ever be another Mailman2 release beyond
v2.1.30.  Stephen, why do you say there will be? Do you have the project
authority to make that statement?  Who do I beleive?

>  > 3. The decision to use Django. Maybe great for Python users
> 
> This makes no sense to me.  

I'm no fan of PHP, but I'd bet that a majority of web frontend
developers, who "Never learned Django" would say that using Django
"makes no sense to" them.  What I'm reading between the lines is that
nothing but Django was considered for MM3 (by "we") and everything else
is inferior and not worth the time.  I'd love to be wrong on that.

> 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!)

MM3 has been on python.org for a while, was it not noticed there either?

>  > 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 


That frightens me a bit.


> 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.

Best wishes,

-Jim P.