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. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org