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

[Stephen J. Turnbull]

Mark Sapiro writes:

 > Well, Steve channeled me earlier, so I'll return the favor.

And did it with extreme precision and accuracy.  Sorry if I created
any misunderstandings.

The only thing I have to add is that mailman-users@python.org is not
going away.  Furthermore, I expect that Mark and I, at least, will be
here for the foreseeable future.  That's because not only are existing
Mailman 2 installations not going away any time soon, there's every
reason to believe that people will continue installing Mailman 2 for
quite some time (even if it might be more convenient for *us* if
everybody would switch to Mailman 3 ;-).

Steve

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

Re: [Mailman-Users] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

[Stephen J. Turnbull]

Phil Stracchino writes:
 > On 2020-02-28 05:44, Stephen J. Turnbull wrote:

 > > str in Python 1, and the history of Mailman as an MLM for an American
 > > rock band (who needs no steekin' accents, we just hammer and bend the
 > > strings!)
 > 
 > This is clearly a story I didn't know.  :)  And now I'm curious...

John Viega was a friend of somebody in the Dave Matthews Band, maybe
Matthews himself.  In the mid-90s, they needed a mailing list to tell
people where they were playing, John didn't like any of the MLMs
available, so he wrote Mailman.  For more info, you'd have to chase
down John or Barry Warsaw, I think.  Maybe Mark knows more.

Barry wrote a chapter on Mailman in "The Architecture of Open Source
Applications", there is some historical stuff in there.  And
https://www.google.com/search?client=firefox-b-d&q=dave+matthews+band+GNU+Mailman
brings up a bunch of relevant-looking links.

Thanks for asking, I may have to follow some of those myself!

Steve

P.S. It is a great story, and a great advert for free/open source
software!

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

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

[Stephen J. Turnbull]

Brian Carpenter writes:
 > On 2/28/20 1:55 PM, Mark Sapiro wrote:
 > > Quite a few core settings are not exposed in Postorius but we're
 > > chipping away at that.
 > 
 > Is there a list somewhere to see what core settings have not been 
 > exposed in Postorius yet?

Implicit in the Postorius UI and the list of REST API endpoints. ;-)
Making that explicit is part of the task I proposed for myself.

I don't think that there are a lot.

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

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

[Stephen J. Turnbull]

@mailman-users
I'm going to get into a lot of design here, so I'm moving the thread to
mailman-develop...@python.org.  Reply-To set; please respect.  Brian
kept in Reply-To as a courtesy, don't know if he's subscribed over there.

@mailman-developers Brian is planning to develop an alternative web UI
for admin and archives.  I don't see this as a disincentive to
Postorius or HyperKitty development (proposed implementation language
is PHP, so we'll still need something we can support that we can
bundle), and alternatives have always been part of the vision.  I for
one plan to cooperate, and hope others feel the same.  Thread starts
here on mailman-users:

https://www.mail-archive.com/mailman-users@python.org/msg72530.html

@Brian
If you aren't subscribed to mailman-developers, and don't want to
subscribe,, I'll try to keep you in the loop.

Brian Carpenter writes:

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

The Python developers looked at Discourse, I think there's actually a
fair amount of activity.  "I think" because I don't participate in
their forum server, not even entirely sure it's Discourse (checked, it
is).  I don't miss it at all.  I don't think the Discourse users miss
mailing lists at all.  There seems to be near zero crosstalk, even
less crosstalk between Discourse and the lists than there is between
the lists and the issue tracker.

I don't know what would happen with better integration.  Discourse
integration of email, uh, "is poor" IMHO, which in my opinion is an
indication that integration is somewhere between very hard and
impossible -- the original author of Discourse seems to be a brilliant
designer and programmer, with plenty of sympathy for user needs.  If
he didn't do it well, it's surely not at all easy.  A lot of people
feel as you do that "both" is the right answer, and there certainly
was a lot of demand for "both" in Python when Discourse was set up
there.

 > I just think the current interfaces and the decision to go with
 > Django has hurt Mailman 3 rather than help it.

That's assuming that the likely alternative was a non-Django framework
rather than "ssh to the host and fire up python mailman.client".  It
was "ssh to the host and fire up python mailman.client", though. ;-)

 > I also mirror Jim's question of who is the "we" in this
 > conversation.

In practice, it was an "I": Barry Warsaw started rewriting the core
around a decade ago.  Then when a beta-ready version became imminent a
few years later, a couple more "I"s, IIRC Terri Oda and Florian Fuchs
wrote much of Postorius (which Barry named), and the Fedora folks did
HyperKitty because they wanted a forum-like archiver it for the Fedora
lists.  For the last few years, both Postorius and HyperKitty have
been maintained and developed by the "Mailman project team", but those
are the folks primarily responsible for the original design decisions
AIUI.

That's how this works.  People see a need, they start hacking on it
without fanfare because they're not committed to it, once they have an
idea of how much work a commitment involves and they're OK with that
they commit and announce, which often has a chilling effect on
independent alternatives, and tends to cut out users who don't know
they need pay attention if they want input to something that will be
available years later (if at all).  I don't know what to do about the
users; Barry did talk about Mailman 3 on-list occasionally, mostly in
response to issues raised about Mailman 2.

 > Why wasn't I invited? :-D

As always in open source, everybody in general is invited, (almost)
nobody gets a personal invitation.[1]  It's unfortunate that the way
things work folks like you and Jim don't find it so easy to pop over
to mailman-developers to find out about these things in advance, but
we also don't want to burden mailman-users with nitty-gritty details
that that may never be relevant to them.

 > What prevents Mailman 3 from replacing Mailman 2 completely?

Mailman 2 ain't broke, so I don't advise people who are happy with
their installations to try to fix it.  Not even by installing Mailman
3. ;-)

 > Is it because of the interfaces for Mailman 3 totally left Mailman
 > 2 behind or was it the decision to use Django?

Mailman 3 cannot be a drop-in replacement for Mailman 2 because by
design Mailman 3 core has no comprehensive administrative or user
access, except via shell access to the Mailman server.  Otherwise, the
only user access is subscribe/unsubscribe by mail, and I don't think
there's any administrative access by mail (maybe moderation can be
enabled? but it would be disabled by default because mail is tres
insecure by default).

 > Cannot Mailman 3 b

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

[Brian Carpenter]

On 2/28/20 1:55 PM, Mark Sapiro wrote:

Quite a few core settings are not exposed in Postorius but we're
chipping away at that.


Is there a list somewhere to see what core settings have not been 
exposed in Postorius yet?


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

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

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

[Mark Sapiro]

On 2/28/20 10:24 AM, Jim Popovitch via Mailman-Users wrote:
> 
> I think that is Brian's and a lot of other people's concern.  3 years to
> implement something into MM3 that was a core feature in MM2.  I realize
> this next question is going to sound bombastic, I assure you it's not
> meant that way:  What other things are missing or not available
> presently in MM3 that are taken for granite in MM2?


I think almost nothing is missing from Mailman core. We don't have
'sibling lists' or 'topics', but other than that, I think it's all there.

Quite a few core settings are not exposed in Postorius but we're
chipping away at that.


>> We are a small project. We have very few people working on Mailman on a
>> regular basis, and everyone is a volunteer, no one is paid. If you want
>> things to happen faster, please contribute.
>>
> 
> ~$ grep "Jim Popovitch" ~/devel/Mailman/NEWS | wc -l
> 10
> 
> I don't think that I've been sitting on the fence, in fact I think I've
> been contributing a lot if you include not just source contributions but
> also the PPAs.  I wouldn't say that I'm a principal developer, but I'm
> not off in some remote corner unfamiliar with the product and project.


I know that you (Jim P) have contributed a lot to MM 2 and we all and I
in particular appreciate that, but I was thinking specifically of MM 3.

Note also that I still spend a lot of time helping people with MM 2
questions. This is time that could otherwise be spent on MM 3. This is a
big part of why I've said 2.1.30 will be the last MM 2 release.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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

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

[Jim Popovitch via Mailman-Users]

On Fri, 2020-02-28 at 10:07 -0800, Mark Sapiro wrote:
> On 2/28/20 6:17 AM, Jim Popovitch via Mailman-Users wrote:
> > 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?
> 
> Well, Steve channeled me earlier, so I'll return the favor. I think
> Steve is saying "Too bad" he is only talking about the choice of PHP as
> a platform rather than Python. We absolutely encourage people to develop
> alternatives to Postorius and HyperKitty for archiving and web
> management of Mailman. I think all Steve is saying is he could be more
> helpful with Python as opposed to PHP.
> 
> See this paragraph:
> 
> > > 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.
> 
> 
> > Who is this "we", you referenced them a few times in this email.
> 
> See the initial paragraph in the Acknowledgements section at
> ;.
> 
> 
> 
> > 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?
> 
> Actually, I have said there will not be another release from the GNU
> Mailman project. That does not preclude anyone from forking that project
> from Launchpad and doing whatever with it.

I get that, but that sounds sharply different than what Stephen was
saying.

> I personally am not interested in porting Mailman 2 to Python 3. That's
> already been done. The result, with a real backend database and some
> extensions such as the concept of "user" that doesn't exist in MM 2, is
> Mailman 3 core.
> 
> 
> > 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.
> 
> The web based archiving and list management we distribute are based on
> Django because that's how the people who developed those things wanted
> to do it.
> 
> The whole point of Mailman 3 is all that stuff is separate from the core
> engine and communicates with core via a REST API, so there can be lots
> of different web management UIs. We knew if we released Mailman 3 core
> only without a web UI for list management and archive access, no one
> would use it, so we needed those things and the people who were willing
> to implement them built what we have.
> 
> We certainly hoped that there would be people like Brian implementing
> alternatives and we're glad to see it.
> 
> > > 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?
> 
> Of course. We began discussing this almost 3 years ago
> ;. The
> implementation was mostly done last year by a GSOC student.

I think that is Brian's and a lot of other people's concern.  3 years to
implement something into MM3 that was a core feature in MM2.  I realize
this next question is going to sound bombastic, I assure you it's not
meant that way:  What other things are missing or not available
presently in MM3 that are taken for granite in MM2?

> We are a small project. We have very few people working on Mailman on a
> regular basis, and everyone is a volunteer, no one is paid. If you want
> things to happen faster, please contribute.
> 

~$ grep "Jim Popovitch" ~/devel/Mailman/NEWS | wc -l
10

I don't think that I've been sitting on the fence, in fact I think I've
been contributing a lot if you include not just source contributions but
also the PPAs.  I wouldn't say that I'm a principal developer, but I'm
not off in some remote corner unfamiliar with the product and project.

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

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

[Mark Sapiro]

On 2/28/20 6:17 AM, Jim Popovitch via Mailman-Users wrote:
> 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?


Well, Steve channeled me earlier, so I'll return the favor. I think
Steve is saying "Too bad" he is only talking about the choice of PHP as
a platform rather than Python. We absolutely encourage people to develop
alternatives to Postorius and HyperKitty for archiving and web
management of Mailman. I think all Steve is saying is he could be more
helpful with Python as opposed to PHP.

See this paragraph:

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



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


See the initial paragraph in the Acknowledgements section at
.



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


Actually, I have said there will not be another release from the GNU
Mailman project. That does not preclude anyone from forking that project
from Launchpad and doing whatever with it.

I personally am not interested in porting Mailman 2 to Python 3. That's
already been done. The result, with a real backend database and some
extensions such as the concept of "user" that doesn't exist in MM 2, is
Mailman 3 core.


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


The web based archiving and list management we distribute are based on
Django because that's how the people who developed those things wanted
to do it.

The whole point of Mailman 3 is all that stuff is separate from the core
engine and communicates with core via a REST API, so there can be lots
of different web management UIs. We knew if we released Mailman 3 core
only without a web UI for list management and archive access, no one
would use it, so we needed those things and the people who were willing
to implement them built what we have.

We certainly hoped that there would be people like Brian implementing
alternatives and we're glad to see it.

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


Of course. We began discussing this almost 3 years ago
. The
implementation was mostly done last year by a GSOC student.

We are a small project. We have very few people working on Mailman on a
regular basis, and everyone is a volunteer, no one is paid. If you want
things to happen faster, please contribute.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
--
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

Re: [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 anyon

Re: [Mailman-Users] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

[Phil Stracchino]

On 2020-02-28 05:44, Stephen J. Turnbull wrote:
> Mailman has the opposite problem.  We *wish* str was Unicode from the
> get-go, but it wasn't, and Mailman 2 is rife with potential encoded/
> decoded confusion because of the nature of email and the dual usage of
> str in Python 1, and the history of Mailman as an MLM for an American
> rock band (who needs no steekin' accents, we just hammer and bend the
> strings!)


This is clearly a story I didn't know.  :)  And now I'm curious...



-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958
--
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

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

[Jim Popovitch via Mailman-Users]

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

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

[Stephen J. Turnbull]

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.

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

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

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

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

Re: [Mailman-Users] The last release from the GNU Mailman project (was: Handling Munged From Addresses)

[Stephen J. Turnbull]

Phil Stracchino writes:

 > Rewriting without breaking is hard.

True.

 > There is a Python framework called Twisted.

Not an example appropriate to Mailman, though.  The Twisted people were
doing amazing things with str, to which Unicode was irrelevant, because
their job was to shovel bytes from here to there correctly but as fast
as possible.  (Mercurial has a similar story, and a similar visceral
hatred for Python 3.)

Mailman has the opposite problem.  We *wish* str was Unicode from the
get-go, but it wasn't, and Mailman 2 is rife with potential encoded/
decoded confusion because of the nature of email and the dual usage of
str in Python 1, and the history of Mailman as an MLM for an American
rock band (who needs no steekin' accents, we just hammer and bend the
strings!)  There are two decades of hacks and patches in Mailman 2 to
catch the squirmers that somehow manage to be str where unicode is
needed or vice versa, and every single one of those would need to be
reverse engineered in a Python 3 environment.  Not a job I would want
to do: like Barry, I would rewrite from scratch (and probably redesign
as well).  But every part converted would be a joy to work with in
the future.

 > As best I can determine, the task of updating it to be Python 3
 > compatible has now been under way for ten years (with most of that
 > time, only one person working on it).

But that's because Python 3 deliberately encouraged decoding streams
of bytes, by making it hard to process bytes the same way as str in
Python 2.  It wouldn't have been hard to make the bytes type identical
to str except for the internal representation, so that programs like
Twisted and Mercurial would just need to be converted so that
*everything* was bytes except for the error messages.  But that was
deliberately avoided: a lot of (Python 2) str methods were not
inherited by bytes.  (In fact, some were re-added later, but too late
to make the bit-shovelers happy.)  So the Twisted people hated Python
3 with a passion.

I'm not surprised that only one person would work on the port, I'm
surprised they found even one!

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