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