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

[Brian Carpenter]

On 2/28/20 5:52 AM, Stephen J. Turnbull wrote:
> 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.


Help with interfacing with Mailman Core via REST will be nice to have. 
My programmer was happy to hear that Mailman core utilized REST but I am 
sure he may have some questions. I have a Discord server setup for 
development communication purposes that I can add you and hopefully Mark 
Sapiro to it if you want. We are also setting up the project on Gitlab 
as a private repository for now.

Usability testing is also very important and the new admin interface 
will need it. This is another part someone like you can be of an immense 
help. I am open to any sort of volunteers at this point.


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

I agree and understand. The forum side is not being considered at this 
time until we get the admin interface nailed down. Right now I am 
looking at Discourse as a motivation for developing the forum side. I 
also think for mailing lists to survive in the future, integrating both 
approaches to communications is what modern users are looking for. I 
also think the approach Mailman 3 core did with using a database and 
REST api is brilliant and forward thinking. I just think the current 
interfaces and the decision to go with Django has hurt Mailman 3 rather 
than help it.

I also mirror Jim's question of who is the "we" in this conversation. 
Why wasn't I invited? :-D


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

What prevents Mailman 3 from replacing Mailman 2 completely? Is it 
because of the interfaces for Mailman 3 totally left Mailman 2 behind or 
was it the decision to use Django? Cannot Mailman 3 be used as a 
standalone 'traditional' mailing list without the need for something 
like Hyperkitty? Can Pipermail be modified to work with Mailman 3 as 
perhaps a stopgap for Mailman 2 users to feel more comfortable with 
migrating to Mailman 3? I host hundreds of Mailman 2 lists and I cannot 
get my clients interested in Mailman 3. It doesn't have all of the 
features that Mailman 2 has when it comes to list settings, at least not 
visible and Hyperkitty is just not impressive to look at when it comes 
to providing a community feel.

I want to research to see if it is possible to provide a browser base 
interface to convert/import a Mailman 2 list into a Mailman 3 list 
without the need of using a command line. Again I am just focusing on 
the list (admin) settings to be imported at this point not archives into 
a forum setting.


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

I assume Django was primarily chosen was because it was written in 
Python. Maybe I am wrong here.  My main problem with Django is you have 
to handle a 3rd interface with Mailman 3. So we have three: Postorius, 
Hyperkitty, and Django. When it comes to a U.I. perspective, Django's 
admin interface leaves a lot to desire. I am hoping to merge the need to 
use two interfaces for administration of a mailman 3 list to one, 
beautiful, easy to use, superfast and glorious administrative interface. 
In other words, One Admin Interface To Rule Them All. I am having some 
fun here but there is a lot of truth that describes my intentions. When 
I first explored using Mailman 3 and I came across the word: Django, I 
said "what the heck is that???". I am pretty sure I am not the only with 
that response. I am still, btw, saying that about Django because I am 
having a very difficult time wrapping my head around its logic.


> 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 am not trying to blame anyone here. I just seems to me there is a lot 
of confusion with the use of Mailman 3.

The problem is the discrepancies between the versions. Once bounce 
processing shows up in Postorius that discrepancy will spread even 
further. The confusing state of installation documentation is also a 
serious problem. I ended up writing my own that I can get consistent 
results from with installing Mailman 3 on new servers. So one of my 
goals in coming up with a new approach is to make the full setup of a 
Mailman 3 server far easier to do AND document.


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

That is fine but what I did not see is the use of U.I. designers. 
Developers make the WORST U.I. designers. U.I. design in my opinion will 
seriously hinder the acceptance of an application no matter how great it 
is. This is good information to know regardless so thank you for sharing.

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

So where was this encouragement? What larger platform did you have in 
mind to integrate Mailman lists into? I am still surprised to see no one 
has come up with a new interface for Mailman 3. I think it is important 
to find out why that is but maybe in another discussion thread.

 From what I can see Mailman 3 core is rock solid. Using a database and 
the REST api was a great move so for me, that leaves the actually public 
facing interfaces to be scrutinized and that is what I have done. Based 
upon my observations  I decided to try to do something about what I see 
as some glaring weaknesses in Postorius/Django Admin/Hyperkitty.


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

Mark is awesome and I have a great working relationship with him via 
these lists throughout the years. I believe I will have that with him in 
the future as well.

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

Will do and thank you for your thoughtful reply.

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

Sounds great!

-- 
Please let me know if you need further assistance.

Thank you for your business. We appreciate our clients.
Brian Carpenter
EMWD.com

--
EMWD's Knowledgebase:
https://clientarea.emwd.com/index.php/knowledgebase

EMWD's Community Forums
http://discourse.emwd.com/