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.