On 8/26/20 3:14 PM, Chip Davis wrote:

All of my dozen Mailman instances run on shared servers.  I have no control over the release/distro on which I am hosted.  But my providers have a bazillion (est.) customers running Mailman2 and, for a number of reasons, are not terribly eager to force us all to convert to Mailman3.  By all reports, it is not an easy migration, nor are all features supported.  From their standpoint, maintaining a stable, if backlevel, Python2 to support MM2 is merely a matter of DASD, with far lower support costs than moving to Py3/MM3.

I think Jim's conclusion of MM2's continued viability is valid, and the idea of having a subset of the dev team continue to support/enhance it is a good idea.  And I like the "Classic Mailman" moniker. :-)

Python 3 is already a part of all major linux distributions. So the framework should already be there for a Mailman 3 installation. As for migrating a Mailman 2 list to Mailman 3, that is easy. The Mailman developers have come up with 2 scripts that do a great job of migrating Mailman 2 lists into a Mailman 3 server.

What happens when another "Dmarc" occurs? That event dramatically impacted mailing lists everywhere. At the time, only Mailman 2 needed to be patched and the Mailman developers did a great job of doing so quickly. However would that happen now if such an event repeated itself? Most likely not. Mailman 3 would get the attention and rightfully so.

You are all looking at the wrong thing here. The real question here is why are you not wanting to move to a Mailman 3 environment? It's not hard to install anymore. It has a future. It is modern. It as a long life expectancy and, most importantly, its being supported and developed.

I think the issue here is money and fear. Cheap cPanel hosts include Mailman 2 with their budget hosting packages and I am pretty sure that is who you are using. Well fine, then let those hosts take on the responsibility of keeping Mailman 2 up to date. That is what open source is all about. For me, Mailman 2 is a dinosaur and its interface is over 20 years old. Mailman 3 is entering the world of modern web development and that is a great thing for users of Mailman. There are still users of Majordomo. But they are very few now and for good reason. Mailing lists are evolving and have moved on.

Get off a ship that is no longer sailing ahead and wants to instead to permanently anchor in place. It's ok, the new ship is more modern and has AC!

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

On 8/26/20 6:25 PM, Carl Zwanzig wrote:

As someone regularly uses and maintains a fair bit of old and antique machinery, MM2 still has a lot of life in it. Yes, the original team isn't going to do much with it, but others probably will. And for someone who wants to run a few simple lists* , MM3 is, um, rather a heavyweight. If I'm reading things correctly, in addition to the web server you need python3, django, a sass compiler (w/ ruby overhead), anything else? It certainly doesn't look as easy to install or configure as MM2.

MM2 has some life. That is correct. MM3 has far more. As someone who has now installed Mailman 3 multiple times, I say from experience, it is very easy to install AND to keep up to date. The server overhead is pretty low as well. So again, the wording you chose is misleading. Installing the environment for a MM3 setup is very easy on a modern linux distribution.

*(I have 3 lists, at most 50 people on each, hardly ever any changes)

So they will not notice a migration to Mailman 3 at all then.

Also, from https://docs.mailman3.org/en/latest/pre-installation-guide.html "The short version is that as of now, upgrading from Mailman 2.1 to Mailman 3.1 is buggy."

I am pretty sure that documentation is old. Here is a quote from the above page:

"Now the long version. Because of the changes in Database Schema, migrating from Mailman 2.1 to Mailman 3.1 is not very easy, though it can be done with some scripting. We are working on it and it should be working soon, we don’t have an exact timeline on it though."

Well they did come up with two scripts for migrating MM2 lists to MM3 and they have been out for a while. I just migrated over 60 MM2 lists to our Mailman 3 cloud environment without a single error. List settings, members, and archives were all migrated easily.

So, it's likely that a lot of people will still be using MM2 for at least a few years (heck there are are Solaris -7- systems out there, happily running production code). That ship is happily performing it's daily passenger runs.

That is good as long as no major "DMARC" events come along. Nobody is complaining that folks are using MM2. But I am seeing some complaints pointed at the MM developers for no longer willing to develop MM2. See, the problem here is, the developers did develop and improve the Mailman project, its just now called Mailman 3. So embrace and respect their hard work and move your dang lists to Mailman 3! (I am jesting with the exclamation point.)

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

On 8/26/20 7:20 PM, Carl Zwanzig wrote:

On 8/26/2020 3:50 PM, Brian Carpenter wrote:

...

On 8/26/20 6:25 PM, Carl Zwanzig wrote:

...

So they will not notice a migration to Mailman 3 at all then.

You miss the point- _I'll_ notice, I'm the one who'd be doing the work.

Well, I am sorry to suggest there be some work to be done in a migration.

...

...

Also, from https://docs.mailman3.org/en/latest/pre-installation-guide.html "The short version is that as of now, upgrading from Mailman 2.1 to Mailman 3.1 is buggy."

I am pretty sure that documentation is old. Here is a quote from the above page: [...]

Old? You've quoted the next paragraph on the same page.

So? I did that to prove that the document was outdated. That's all.

And why would I use linux when I have FreeBSD? :)

...

That is good as long as no major "DMARC" events come along. Nobody is complaining that folks are using MM2. But I am seeing some complaints pointed at the MM developers for no longer willing to develop MM2.

That's a completely separate topic and you'll have noticed that I'm not one of the complainers.

...

See, the problem here is, the developers did develop and improve the Mailman project, its just now called Mailman 3. So embrace and respect their hard work and move your dang lists to Mailman 3!

When I get to it, maybe in 2022.

Ok. But that then goes against your original premise. MM2 isn't broke so why move from it. Ever.

The thing is- no matter how much you may want people to "upgrade", there just aren't sufficient reasons for potentially a lot of small list operators. Perhaps I'm a luddite- I drive a 15 year old car because it works, most of my home systems are 5+ years old because they work and are plenty fast for the load, I use a 18? year old Brother printer because it works, etc. When one of them stops working it'll get replaced (if I can't repair it). There is little reason to replace things that still function as much as one needs.

Ok. Except this isn't about just list operators, or moderators, but also list members. There are a lot of roles involved here. Mailman 3 is the future. That REST api is awesome. It allowed me to do things with Mailman 3 that just wasn't possible with Mailman 2. I think some of the criticisms is really directed at Postorius/Hyperkitty and not Mailman 3 core. The thing about those interfaces is they too can be improved continually, and due to the use of Python 3 and modern web development, have far more potential to make the lives of list owners, moderators, and members more easier and productive. You are not going to see that with Mailman 2. You like using antiques? Ok, go for it.

I heartily agree. Developers move on all the time and sometimes others pick up the codebase and run with it. Embrace that.

Nope. I am going with improving the quality of life for list owners, moderators, and members by embracing Mailman 3 and its REST api.

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

Brian Carpenter writes:

On 8/26/20 6:25 PM, Carl Zwanzig wrote:

...

As someone regularly uses and maintains a fair bit of old and antique machinery, MM2 still has a lot of life in it.

In particular, MM2 L10N supports a couple dozen languages, including the major Han languages and dialects, and I think Hebrew and Arabic. MM3 supports English, French, German, and now Italian.

MM2 has some life. That is correct. MM3 has far more.

Thank you both for your support. Of course, you're both right. ;-)

Brian, do you see the presence of lots of MM2 installations around the 'net as a threat or irritation for you or your business? I don't see that, but you know your business and I don't. Or are you taking the users' point of view, and arguing that the features of Mailman 3 and possible risks to Mailman 2 installations make migration the "right thing"?

The point is that I don't see a lot of direct harm to third parties from maintaining existing MM2 installations, if their owners are willing to accept the risks that come with an unsupported software stack. I don't disagree that for-profit services that offer these are irresponsible, but I don't see how that hurts you or us, given that we don't support that stack any more.

That is good as long as no major "DMARC" events come along.

That's a very good point. There are major risks to using Internet- facing applications that lack an experienced, active development team. But that's up to the users to decide, while monitoring just how active Jim's team turns out to be.

I think Jim should very much take this to heart, as well as thinking about the fact that we get several CVEs a year, which will be his job to deal with. I don't lose sleep over the CVEs (they're all 1s and 2s recently, and Mark did almost all the work before I could get started :-), but DMARC cost me a lot of sleep.

But I am seeing some complaints pointed at the MM developers for no longer willing to develop MM2.

That's just people blowing off steam, with a few people like Jim stepping forward and saying they'd like to serve the occasional need not served by MM2 as is or migration to MM3. Overall I take it as a compliment to the Mailman 2 developers, and Jim is a credit to the community. I have not seen the bitterness against Mailman 3 that was directed from several quarters against Python 3, just a lament about the loss of Mailman 2.

On 8/27/20 3:34 AM, Jim Popovitch via Mailman-Users wrote:

Stephen, just who do you think did the DMARC research and work in MM2? Phil, Mark, care to chime in on this?

The original DMARC mitigation work was contributed by Franck Martin of LinkedIn and was in Mailman as a site optional feature in Mailman 2.1 16 (16-Oct-2013) prior to Yahoo publishing DMARC p=reject in April of 2014.

The implementation of DNS lookup to enable DMARC mitigations to be applied conditionally based on the From domain's DMARC policy introduced in Mailman 2.1.18 (03-May-2014) was contributed by Jim Popovitch and Phil Pennock

See <https://bazaar.launchpad.net/~mailman-coders/mailman/2.1/view/head:/NEWS#L1070>.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On Sat, 2020-08-29 at 03:53 +0900, Stephen J. Turnbull wrote:

Jim Popovitch via Mailman-Users writes:

...

Again with the "Jim's team". Those other guys, that other group, them folks.... That's nauseating to hear from you Stephen.

I use the word "team" to describe people who work together closely to achieve common goals. That's just English.

Yet, (as you write in the 4 paragraphs below) you see no benefit of working together closely with anyone in favor of continuing work on mm2. So which use of "team" is it Stephen?

The team I'm on, the GNU Mailman Project whose core members control access to Mailman resources ranging from mailing list moderation to GSoC slots, has the goal of developing, maintaining and promoting Mailman 3, while winding down Mailman 2 gracefully. Mark's "gatekeeping" is a deliberate strategy to that end that is an economical use of our resources. Until you spoke up, there wasn't really an alternative anyway given Mark's expressed desire to EOL his support of Mailman 2.

You have a different goal, maintaining, promoting, and developing Mailman 2. As far as I know, you have no interest in doing the same for Mailman 3 at this time. I believe that is also true of others who have expressed interest in your proposal.

I don't see how you can question that these are different teams. We don't need to work together and we won't work together on 99% of what either team does. I do not understand why you take insult at references to this simple fact, and spew abuse in return.

This abuse is quite different from getting upset at the GNU Mailman Project's policy of deprecating Mailman 2. That imposes real costs on you. I understand why that frustrates you. I understand why you want to share in our resources and our reputation that we built up and we maintain, rather than fork a new project. And you know what? Even though your goal of promoting Mailman 2 is apparently opposed to our goal of winding down Mailman 2, it presents a great opportunity to do it with grace. I understand and to some extent agree with Brian's concerns about technical debt and irresponsible providers. But I don't really see how a shoot-the-prisoner approach to Mailman 2 EOL addresses the technical debt and provider issues given the switching costs that Mailman 2 users still face. So I think it would benefit Mailman 2 users in the community to take up a friendly offer to maintain Mailman 2, and not really harm our goals.

Problem is, you are not friendly. You are hostile and abusive, and I don't understand why.

Because friendly got us all the way to this point, and it's a point that could have, and should have, been avoided by not alienating mm2 users and site owners. Your "team" did that alienation, don't try to throw it off as the fault of others who are identifying it.

Ball's in your court, Jim.

...

Stephen, just who do you think did the DMARC research and work in MM2?

What's your point? Again, you seem to have taken offense, but I'm not sure why. The only contribution I deprecated was my own, and I'm baffled at the connection to who did DMARC work.

I'm baffled because you claimed to have headaches from doing all the DMARC work, and, honestly, you weren't a part of the DMARC work that Mark, Phil and I did. And up until our work there was no widely used or well known DMARC solution in mm2 other than from_is_list (which, lets face it, hardly anybody knew about or used). Frank's patch (from 2012) was not really a solution, and Mark did most of the work on that. Here's the commit log: https://code.launchpad.net/~mlm-author/mailman/2.1-author/+merge/115035

Here's the source of my DMARC work: https://code.launchpad.net/~jimpop/mailman/dmarc-reject Here's Phil's contributions: https://code.launchpad.net/~phil.pennock/mailman/dmarc-reject

And if you look in this list you will find several other merges from me on DMARC handling: https://code.launchpad.net/%7Emailman-coders/mailman/2.1/+merges What I can't find on that list is contributions/merges from you Stephen.

To answer your question, though, Franck Martin of LinkedIn and DMARC contributed the original from_is_list patch. I contributed an alternative, RFC-conforming wrapper approach (that wasn't useful because of Apple Mail's mishandling message/rfc-822 parts), and liaised with the DMARC Consortium. You did something that I forget exactly, IIRC related to the DNS fiddling that enabled the mitigations only on p=reject domains, which made from_is_list a lot more palatable. Mark did the integration of about 2 dozen patches, testing, much of the documentation, and cut several releases specifically to ensure that the users got the best DMARC handling we could offer right away. Other people contributed various improvements that I don't recall offhand, I think the above are the main ones though. And we owe a debt to a few PyPI packages.

I find it ironic (and humorous) that you know about your and Frank's contributions and "forget" about my, Mark's and Phil's work. Rose colored glasses?

-Jim P.

For clarity- As I understand, given the language differences MM3 was a complete rewrite of MM2, so the only common parts are some features, the use of python (at all), and the name. Yes? Therefore anyone working on MM2 isn't impeding the work on MM3, especially if they weren't going to work on MM3 anyway.

On 8/28/2020 3:02 PM, Chip Davis wrote:

[...] These are three quite diverse codebases, each with their contributors/committers and project-level discussion groups, but there is quite a bit of cross-team communication and collaboration.

Just like with net/open/free BSD (and related or spinoff projects), and with things being ported between them and to/from linux. The world still hasn't ended.

It's all well and good to say "_We_ don't want to maintain this code.", it's vastly different to say "Pay no attention to that GPL, no one is allowed to maintain or improve that code." With the former, might as well welcome in a group of people to the overall project with the express intent of maintaining 2.x. With the latter, it's off into saying "no maintenance, no changes, nothing" and probably the same group of people will fork off the code-base, maybe change the name, and do their maintenance/updates anyway.

Or... it's pretty likely that MM2 maintenance, and maybe improvements, will continue in some fashion. The question is whether that's under the auspices of the gnu-mailman project or in a fork. If the existing gnu-mailman team doesn't want new members working on old code, and that's the way it sounds, just say so and give the blessing for a code fork.

Later,

z!

On 8/28/20 11:47 PM, Carl Zwanzig wrote:

If the existing gnu-mailman team doesn't want new members working on old code, and that's the way it sounds, just say so and give the blessing for a code fork.

We never said that. We only asked that these potential new members actually ask to join the GNU Mailman project as members.

Note: within the hour I am going off-line for 12 days so you won't hear more from me for a while.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Thank you, Steve, for your thoughtful and measured reply.  I have a clearer picture of the ramifications of Jim's proposal, to the degree that he has specified it.  The longer the thread festered, the fewer salient points were made, so I can't say that I support it or not.  But it's not my call in the first place.

I'm glad you have no quarrel with me.  I am merely a Mailman admin with no control over any of my installations.  I hope that by the time my ISPs drop MM2, there will be ample tools to make the conversion to MM3 relatively painless.  Despite an exhaustive search, I can find no suitable and affordable alternative.

BTW, the original Rexx interpreter was written in IBM Assembler (proprietary), Regina in C (GPL), ooRexx in C/C++ (CPL), NetRexx in NetRexx(!) (CPL), and BSF4ooRexx in ooRexx (CPL/AL).  There has been no "branching" whatsoever.  Yet there is a lively cross-platform collaboration when issues arise, from architecture down to patch. And yes, sometimes it can get testy. ;-)

Thank you for you patience.  I consider this matter closed.

-Chip-

On 8/30/2020 1:29 AM, Stephen J. Turnbull wrote:

I wrote a long screed, full of piss and vinegar. But on reflection, clearly nobody is reading what I wrote earlier, so let's try pithy and dry. It's still long. :-(

Chip Davis writes:

...

OK guys, what's really going on here?

I don't know. I can tell you I'm done with Jim. You'll have to ask him about what he thinks is going on.

I have differences of opinion with you and Carl, but no quarrel.

...

Is this about turf?

Not on our side. I have genuine concerns. In Mark's most recent post, he writes:

...

We only asked that these potential new members actually ask to join the GNU Mailman project as members.

That doesn't look like a concern with turf to me. Mark may not have the same concerns I do, or any at all, I don't know. We'll have to wait until he gets back. In the meantime, I'll lay out mine.

 > Is there something about Jim's proposal that requires resources > (money, proprietary code, prestige, etc.) from the GNU Mailman group?

Mailman is a GNU project. Under the GPL, Jim's proposal *needs* no resources from the GNU Mailman Project, and no blessing from us, either. He has the code, and the physical resources are easy to come by elsewhere.

Certainly it makes economic sense to use the existing repository and other project resources to support further Mailman 2 development. It won't cost Mailman 3 or the Mailman Project anything to share. But nobody else has any *right* to any of those resources, and especially not to the time that Mark and I devote to user support. If you think otherwise, you are wrong both as a matter of law and as a matter of free software philosophy.

In this connection, Carl Zwanzig writes:

...

it's vastly different to say "Pay no attention to that GPL, no one is allowed to maintain or improve that code."

That's incoherent. The complaint is that people *are* maintaining and improving the code, but we don't allow them to use our resources and reputation to distribute their code. That complaint is groundless. It is fully within the GPL, letter and spirit, to refuse to distribute code, whether others' or our own. The spirit of the GPL is that you can use your own resources to distribute both your code and ours.

Just ask politely, and if you want my support for you to freely commit to and distribute from the project's Mailman 2 branch, I ask you to commit to providing support for all its users.

Or don't commit to serving users, just don't free-ride on the Mailman name and you can have my support. That was the idea of my original request to Jim.

Back to Chip:

...

[Are you] genuinely concerned that the continued viability of MM2 would be a threat to MM3[?]

Brian may be, and I'd like to hear why. But at present I am not.

My concern is that a small group of highly competent power users will take over the Mailman 2 repo, Mark and I will disengage from this list and Mailman 2 bug channels, and support for ordinary Mailman 2 users will go in the toilet because the new team is focused on developing an EOL application in an EOL language, not on user support.

...

I have a little experience [with multiple "branches" of REXX] here.

With all due respect, I don't think it's relevant to what Jim has proposed so far. There's a detailed explanation in the "screed", but the gist is that Mailman 2 and Mailman 3 use completely different architectures and interfaces, so expertise simply doesn't transfer between them. Of recently active developers only Mark and I have experience with both code bases, and I at least want to wash my hands of Mailman 2. AFAICS, the developer teams will have little to talk about with each other.

As far as the communities go, perhaps we could work together somewhat. We have a common history, we support the same kind of admins and list users, there's going to be movement across the Mailman 2 vs. Mailman 3 boundary. We share the goal (for us, secondary) of providing good day-to-day support to folks still using Mailman 2.

But all Jim has proposed so far is to commit and distribute his team's patches. I don't mean to be unnecessarily unpleasant: that's a fact. You've all paid lip service to the Mailman 2 community, but are you committed to community support? Who's going to moderate this list? Who's going to be here day in and day out answering both interesting bugs and boring FAQs? What is to be done about users whose preferred distros EOL their Mailman 2 packages?

 > I can see that it won't immediately lift the entire burden of MM2 > off of Mark's shoulders,

As far as Mark is concerned, Mailman 2 is EOL. So it's an objective fact that this change doesn't lift burden, it *adds* burden: new code, new questions, new bugs, new releases.

The question is whether Mark will feel free to quit supporting Mailman 2. I sure will -- there will be a new maintainer to point users at.

...

simply declaring EOL on MM2 and leaving thousands of admins in the lurch.

Mark has already declared EOL a couple of times, although in practice we (that includes you folks on an as-available basis, tyvm!) continue to support it. There is no "lurch". But I do not believe that the "thousands of admins" want new development. What we see day in and day out are admins happy with Mailman 2 as it is, but they want help with upgrading from source or spam filters, etc.

As far as I can see, where Mailman 2 EOL pinches is a smallish number of power users who would like to use our resources (repo, mailing list, and maybe our pipeline to distros) to share patches as did the legendary Apache HTTPd dev group. Nothing wrong with that. We're discussing it right here.

But understand that we have a reputation to protect. Understand that we don't want to be spammed by Mailman 2 users who aren't getting the help they need from the new dev crew. And understand that we want those users to get a semblance of the support we currently give them, but believe we could not give if we were doing active development on Mailman 2 at the same time.

...

What am I missing?

A Mailman 2 branch open for development.

It should be clear at this point what directions discussion might go to get my support. You'll have to ask Mark about his desiderata when he gets back. Abhilash and the others will likely go with what Mark and I recommend, but we'll see when the time comes.

Regards, Steve

Jim Popovitch via Mailman-Users wrote:

On Sun, 2020-08-30 at 14:29 +0900, Stephen J. Turnbull wrote:

...

I wrote a long screed, full of piss and vinegar. But on reflection, clearly nobody is reading what I wrote earlier, so let's try pithy and dry. It's still long. :-(

Chip Davis writes:

...

OK guys, what's really going on here?

I don't know. I can tell you I'm done with Jim. You'll have to ask him about what he thinks is going on.

I'm more than happy to detail it. Stephen and Mark want to move on, and get away from mm2, they want everyone else to follow them to mm3. They feel that *their* reputations would be hurt if others stayed back and continued to work on what they are abandoning.

-Jim P.

Risky to state what one believes other people's feeling are.

Mark has been a great help to many with MM2, self included, He & all who have helped with MM2 deserve thanks.

Inevitably there comes a time when some want to reduce time on MM2 to spend that time on MM3. Equally, some of us will not want to have to find time to learn new MM3 tools & reconfig, so will want MM2 maintained by whoever can help on that.

Best chance to arrange amicable solution to MM2 maintenance is when feelings cool, so a few days pause would probably help.

Cheers, Julian

Julian Stacey, Consultant Sys. Engineer, BSD Linux http://berklix.com/jhs/ Crash Brexit Dec. 2020 aids speculators & Russia. http://berklix.uk/brexit/

On Sun, 2020-09-13 at 15:36 +0000, Mark Sapiro wrote:

OK, I'm back and more or less caught up so I'm ready to continue this discussion.

In his initial post in this thread, Jim suggests that he and others want to join the Mailman Coders team on Launchpad in order to commit to the Mailman 2.1 branch there. In a thread on the merge proposal that started this, Jim quotes my conjecture that he wants not only commit permission, but also the ability to make releases and distribute them to the appropriate download locations, and says that's "overkill". He also notes my suggestion that he make a proposal to mailman-cabal@python.org which he has not yet done. [1] I mentioned that previously in this thread [2] and Jim replied that my suggestions were "over the top" [3].

So much for background. Here's my current position. Steve has presented a summary of issues [4] with which I agree. For my part, I have stated that I am willing to continue in my role as Mailman 2.1 release manager and to fix critical bugs and security issues and commit i18n updates, but not implement new features. I am also happy to continue to support Mailman 2.1 users via this list. In fact, I just reported and fixed a bug [5].

However, if third parties are making changes to the code base, I can no longer make signed releases of code that I haven't audited, and this auditing is what I don't want to do.

Jim seems to want to be able to make these changes, but seems unwilling to take over as release manager. So, what is the value of these changes if there is never another release?

I think that's probably enough for this post. I will try to answer any follow-ups.

[1] https://code.launchpad.net/~jks/mailman/hcaptcha/+merge/389691/comments/1024... [2] https://mail.python.org/archives/list/mailman-users@python.org/message/ADOK7... [3] https://mail.python.org/archives/list/mailman-users@python.org/message/RUZCF... [4] https://mail.python.org/archives/list/mailman-users@python.org/message/XCGIW... [5] https://bugs.launchpad.net/mailman/+bug/1895451

Since it's not clear enough, my "overkill" statement about specifically about the laundry list of things that Mark said I would need commit and update access to [1], which seemed above and beyond necessary to me. More specifically that list of access-to-everything seems to me like a jellybean test. e.g. "Ask for all of this so that it is impossible for you get get any of it".

1. https://code.launchpad.net/~jks/mailman/hcaptcha/+merge/389691/comments/1024...

I standby my feelings that some people want to quietly run away from this established product and make it impossible for any others to take over. See Stephens previous comments about how there was no way he could or would work with anyone working on mm2 because it was against his objectives, yet he wanted to remain as one of the few in the Cabal (really just who is the Cabal these days?), thereby preventing any mm2 people from being in the Cabal, the Cabal that Mark just said myself and anyone else would need permission and access from. It looks like a rotten egg, it smells like a rotten egg,....

What I want to hear from the Cabal is that there is support and appreciation for efforts by others to carry on with mm2 in any direction it takes them and that their representation in the Cabal is assured.

-Jim P.

On Sun, 2020-09-13 at 09:16 -0700, Mark Sapiro wrote:

On 9/13/20 9:01 AM, Jim Popovitch via Mailman-Users wrote:

...

What I want to hear from the Cabal is that there is support and appreciation for efforts by others to carry on with mm2 in any direction it takes them and that their representation in the Cabal is assured.

So make a proposal to mailman-cabal@python.org

I think at this point the onus is on the Cabal to formally state their position given that we seen waffling about mm2 finality and security releases (yes, it did eventually turn out better than it looked), and comments like this from a current Cabal member:

"...the GNU Mailman Project whose core members control access to Mailman resources ranging from mailing list moderation to GSoC slots, has the goal of developing, maintaining and promoting Mailman 3, while winding down Mailman 2 gracefully."

Just what is the Cabal willing to accept in a proposal?

-Jim P.

Hi all

I am just a user of a Mailman 2 installation on cPanel. And I am reading here because i get some answers to my questions and help if something goes wrong.

As long as cPanel bundles MM2, I need from time to time some support from the real experts. And even if MM2 would not be improved at all in the future, I hope that this list will stay alive.

Christian

-- Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)
Hilfe fuer Strassenkinder in Ghana: http://www.chance-for-children.org

I am loathe, as a lowly list administrator (on cPanel hosts, at that) to participate in the clash of titans,  but this _is_ the "mailman-users" discussion list.  It is somewhat distressing to see so little participation by the Mailman2 users, who will be most affected by any changes in its support.

Speaking as _a_ user, my requirements are simple: 1.  MM2 must continue to work, 2.  support must continue to be provided.

Any proposal that jeopardizes those fundamentals must be rejected.

By "support", I mean everything except new functionality: bug fixes, installation/administration hand-holding, dumb questions not properly answered by the user community, the occasional "Why does Mailman do this?" query, and any number of issues that depend on the encyclopedic institutional knowledge residing in Mark's and Stephen's crania.

This includes structural changes to way email is handled (DMARC, encryption, etc.).  This does not include additional language tables, or any of the issues on my personal laundry list of "I sure wish Mailman had a way to ...".

-Chip-

On 9/13/2020 1:06 PM, Mark Sapiro wrote:

On 9/13/20 9:29 AM, Jim Popovitch via Mailman-Users wrote:

...

Just what is the Cabal willing to accept in a proposal? Try us and see?

My own opinion is I would want a commitment to take over what I currently do including making releases on Launchpad, distributing them to sourceforge and gnu.org, updating version info on https://www.list.org/ (and mirrors) and announcing them. I would be willing to mentor someone through this process.

I would ask for all that because I am not willing to make releases of code I haven't audited, and if I were willing to audit all the changes, we wouldn't be having this conversation at all. And, I don't see what use there is of just updating the branch on Launchpad without making releases.

You may have ideas about how this can work without all that. That's why I think we want to see and discuss your proposal.

HI,

I dont know what planet this user lives on,

"> Speaking as _a_ user, my requirements are simple:

1. MM2 must continue to work,
2. support must continue to be provided."

but really? try telling say Oracle that they MUST continue to support Oracle 8.0, LOL.

This is open source there is no MUST in support. If you think you are entitled to free support for ever you are using the wrong product(s). Except as its open source unlike Oracle you can continue to look after it yourself.

Meanwhile thankyou Mailman team for the great product and support over 15+ years.

regards

Steven

On 9/13/20 12:39 PM, Chip Davis wrote:

Speaking as _a_ user, my requirements are simple: 1.  MM2 must continue to work, 2.  support must continue to be provided.

Any proposal that jeopardizes those fundamentals must be rejected.

By "support", I mean everything except new functionality: bug fixes, installation/administration hand-holding, dumb questions not properly answered by the user community, the occasional "Why does Mailman do this?" query, and any number of issues that depend on the encyclopedic institutional knowledge residing in Mark's and Stephen's crania.

This includes structural changes to way email is handled (DMARC, encryption, etc.).  This does not include additional language tables, or any of the issues on my personal laundry list of "I sure wish Mailman had a way to ...".

This thread started because I refused to accept a merge request to add a new feature, hCAPTCHA, to the subscribe form. The reason I gave was "no new features", although I have other reservations about CAPTCHAs in general.

I think I have made my position clear and I think it includes my doing all the things Chip wants, although I'm 78 years old, and it's not unlikely that I will die before Mailman 2.1 finally does.

What I am opposed to is third parties making changes to the code base and expecting me to continue to make releases, so I ask that any potential group of Mailman 2.1 developers either fork the project in which case, they can do whatever they want with their fork, or if they want to commit changes to the Mailman 2.1 branch on Launchpad that they be willing to take over the entire job.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 9/13/2020 6:17 PM, Chip Davis wrote:

Ironically, I was writing in support of Mark's and Stephen's position on the matter.  As a member of Mark's cohort, the odds are I'll never need a "New! Improved!" MM2, or MM3.

You wish: at some point "they" will upgrade the hardware and/or the OS to fix whatever horrible security hole is ending the world as we know it this week, and the upgrade will kill python 2 compatibility. Or some obscure python 2 library nobody knew existed.

"Them" being cPanel of RedHat or Cluebuntu, or any number of other players who aren't Mark and Stephen.

Dima

On 9/13/2020 7:20 PM, dean.collins@insightplanners.com wrote:

Yay! Most useless, uninformative post of the day!

Are you reading he same mailing list I do? And if yes, the follow-up question: did you notice the threads on getting MM2 to work on centos 7, RedHat 8, and did you ever stop to consider how they relate to

...

...

... the odds are I'll never need a "New! Improved!" MM2, or MM3.

*plonk* Dima

Jim Popovitch via Mailman-Users writes:

See Stephens previous comments about how there was no way he could or would work with anyone working on mm2 because it was against his objectives,

Correction: I will not work with someone who repeatedly misrepresents my positions in the way that the quoted passage does.

On 9/15/20 4:40 AM, Jim Popovitch via Mailman-Users wrote:

I'd use the new MM3 archive of this list to link to your posts, but interacting with it is an abysmal time waste. At a minimum someone should put Brian's HK replacement on python.org?

Brian's Affinity and Empathy are his proprietary work and he has valid reasons for not licensing their use by others.

Would you care to elaborate on why you think interacting with HK is "an abysmal time waste"?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 9/15/20 11:59 AM, Jim Popovitch via Mailman-Users wrote:

Ok, that makes sense. I wonder if we can get him to license/allow a copy for use by Python.org.

Only if they agree to use it on a server on my network with no root access allowed. Since Affinity and Empathy are not python apps, I doubt they would ever agree to that, especially since Postorius and HK are developed with python, howbeit Django projects.

I went to the last link at the bottom of this list's posts and clicked on the (first) item with the same Subject as this email. I paged down into that long page to find the single post that I wanted to link to. After a while I gave up trying to find it because I was distracted by all the out-of-order posts that were displayed there. Go try it yourself, look at how the past post of "I'm done Jim" is listed right after your most recent post today. I get that HK is different than Pipermail, but there's something stylish and simplistic about Pipermail that make it easy to use.

I am not sure if Empathy would be any better but feel free to try:

https://harmonylists.io/empathy/list/affinity-beta.harmonylists.io

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

Jim Popovitch via Mailman-Users writes:

I personally think that you, Stephen, are digging high and low to find any reason for Mailman2 to not continue forward under the Mailman umbrella.

Digging?? Wake up, Jim! It's *official policy* that Mailman 2 will not receive new features under the Mailman umbrella. It has been so for *years*. And the reasons have been the same for just as long: It's because we don't want to support them. Mark and I have both been quite clear about that.

If you will support Mailman 2 going forward as we (ie, mostly Mark) have supported it to date, that would be fine. But you've explicitly denied that you want to do that work. You don't think it's necessary. We think it addresses the needs of the users who need us most, so we'll keep doing it our way, ie, we will support no new features.

Obstruction much?

There you go with the abuse again. But I'll answer you politely.

Mailman is free software. There's no "obstruction" at all, it's almost impossible to obstruct you -- you have the code, it's easy to find well-known places to host your releases and issue tracker, and we're not going to stop you from announcing them here or on the wiki. You don't need anything else.

You demand a bunch of perks: use of the Mailman brand, commit rights in the official Mailman 2 repository, manager access to the tracker (I assume), a seat in the cabal, etc. You also apparently think you have the right to tell Mark and me which releases we should support. My question is: what do our users get in return? If they wanted "bright! new! shiny!", they'd migrate to Mailman 3. I don't see much in the plus column. On the minus side, Mark and I will spend time supporting your new features, time we can't spend on "classic" Mailman 2 issues, Python 2 EOL issues, or on Mailman 3 development, which is what the project is committed to, as Mark and I are.

I don't see that as a good deal for Mark and me, or for the great majority of Mailman 2 users.

If only this were a meeting conducted under Robert's Rules, the Chair would have invoked cloture, or at least referred this issue back to committee.  All interested parties have made their arguments, positions have hardened, and debate has become unrevealing.

Insofar as anything ever dies on the Internet, this abused equine is pinin' for the grassy fjords.

Please, can we convert this into a three-way private conversation, and consign this nearly ninety-entry email thread to history?  My screen isn't wide enough to handle the indentation required.

-Chip-

On 9/15/2020 3:41 PM, Jim Popovitch via Mailman-Users wrote:

On Wed, 2020-09-16 at 03:51 +0900, Stephen J. Turnbull wrote:

...

Jim Popovitch via Mailman-Users writes:

...

I personally think that you, Stephen, are digging high and low to find any reason for Mailman2 to not continue forward under the Mailman umbrella.

Digging?? Wake up, Jim! It's *official policy* that Mailman 2 will not receive new features under the Mailman umbrella. It has been so for *years*. And the reasons have been the same for just as long: It's because we don't want to support them. Mark and I have both been quite clear about that.

If you will support Mailman 2 going forward as we (ie, mostly Mark) have supported it to date, that would be fine. But you've explicitly denied that you want to do that work. You don't think it's necessary. We think it addresses the needs of the users who need us most, so we'll keep doing it our way, ie, we will support no new features. Wait, so you do want to continue to support mm2 users, but you don't want to support them in any fashion if someone else other than you and Mark manages just the new features? (BTW, NEWS lists New Features were added as recently as 2020-April) Do you feel that you would be obligated to support something that was added to mm2 that you didn't feel should be added or that you couldn't provide support for? Is that what this is all about?

...

...

Obstruction much?

There you go with the abuse again. But I'll answer you politely.

Mailman is free software. There's no "obstruction" at all, it's almost impossible to obstruct you -- you have the code, it's easy to find well-known places to host your releases and issue tracker, and we're not going to stop you from announcing them here or on the wiki. You don't need anything else.

You demand a bunch of perks: use of the Mailman brand, commit rights in the official Mailman 2 repository, manager access to the tracker (I assume), a seat in the cabal, etc. I demanded nothing. I was told by Mark that I would need to apply for all those perks (sans the Cabal seat) when all I offered to do was support/test/debug/evaluate/approve new features in launchpad.

...

You also apparently think you have the right to tell Mark and me which releases we should support. No I don't, and I don't know why you can't differentiate between Mailman and yourself. Mailman should, and can, support multiple versions. You and Mark should feel free to contribute wherever you feel comfortable; but I draw the line at you saying mm2 should die because you don't want to support it under the parameters and guidelines designed and established by yourself (and Mark). I think the genuine problem here is that it's a 2 man show when it should be a much larger body.

Now, no one should be shielded from criticism when they attempt to abandon an installed base of users. Remember, we are at this juncture today because several people spoke up, over the past year, about all the repeated "Final Release" warnings. It took at least 2 days of back-n- forth emails just to get someone to say publicly that mm2 security issues would indeed still be addressed going forward (why was it so difficult to come to that reasoning?). Also, don't forget that this time last Summer there were some discussions on this list about how mm2 would be eol on 1/1/2020 because that was the Python team's v2 eol.

...

My question is: what do our users get in return? If they wanted "bright! new! shiny!", they'd migrate to Mailman 3. I don't see much in the plus column. On the minus side, Mark and I will spend time supporting your new features, time we can't spend on "classic" Mailman 2 issues, Python 2 EOL issues, or on Mailman 3 development, which is what the project is committed to, as Mark and I are.

I don't see that as a good deal for Mark and me, or for the great majority of Mailman 2 users. Why just you and Mark? What about any of the other many people who contribute and help in various ways?

-Jim P.

---

Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-leave@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/

On 9/15/20 12:41 PM, Jim Popovitch via Mailman-Users wrote:

I demanded nothing. I was told by Mark that I would need to apply for all those perks (sans the Cabal seat) when all I offered to do was support/test/debug/evaluate/approve new features in launchpad.

I told you to make a proposal to Mailman-cabal@python.org. I suggested what I thought it should include. I don't think I said it had to include all that. See my follow=up at <https://mail.python.org/archives/list/mailman-users@python.org/message/WS5ISNCEOGKEJRJNO3FCXFBCXMJY5ADC/>.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 9/15/20 8:18 PM, Jim Popovitch via Mailman-Users wrote:

A small group, including myself, are planning to present a proposal. We are in the early stage of defining what that will involve, but we are all committed. I've also, as you've probably seen on lp, been focused on pushing my py3 changes for mm2 to get them to the point of usable testing. I'm not anti-mm3 but myself and some others certainly do see the ongoing need for a MLM like mm2.

When you say py3, are you talking about python 3? Are you trying to make mm2 python 3 compatible?

So this labor you and your group are looking to do for MM2, how is this not going to take more time then just migrating to MM3? One of your criticism is that MM3 is complex and it is difficult to install. How is all of this effort you are making staying with a version of Mailman that has been updated (MM2 to MM3), and uses an interface that is over 15 years old productive? I don't see this path you are trying to take as one that is less complex and difficult than just moving to a MM3 environment. At this point, those who use MM2 via cPanel will most likely not benefit from your efforts. Especially if you port MM2 to python 3 (this is an assumption I am making). I don't think cPanel will touch such a version at all.

By the way, with all the problems I have seen with some folks having a difficult time with installing MM2 on this list, I think the arguments that MM3 is too difficult to install (it's not) weakens considerably. I still think non-cPanel MM2 users' time is better spent learning to install MM3 and using it. Or better yet use a Mailman 3 host provider such as myself to make their lives considerably easier.

-- Brian Carpenter Harmonylists.com Emwd.com

I admit I haven’t been following this thread very closely, and don’t intend to do so. (There’s a reason I turned over project management a few years ago :).

Just a couple of points.

On Sep 15, 2020, at 18:11, Brian Carpenter <brian_carpenter@emwd.com> wrote:

When you say py3, are you talking about python 3? Are you trying to make mm2 python 3 compatible?

I think that will be pretty challenging actually. At least, it was when I did it years ago. And unless you’re *really* careful to avoid the temptation to “fix" things along the way, you’ll probably end up with something not too far away from Mailman 3. ;) But hey, it’ll definitely be fun.

The only other point to make is to remember that Mailman is “GNU Mailman”. 2 or 3, it’s still a GNU project, which means more than just being covered under some flavor of the GPL. Just saying that if responsibility for MM2 is transferred, you’ll need to coordinate with the GNU project.

Cheers, and good luck! -Barry

Cleaned up the @s.

Jonathan M writes:

What would be fun is a “Mailman 2 lookalike” Python 3 user interface for Mailman 3, complete with Times New Roman and Courier.

The archiver part would be relatively easy to do; Pipermail is probably fairly easy to disentangle from Mailman 2. I can't speak to how easy it would be to translate to Python 3.

Replacing Postorius with a Mailman 2 lookalike would probabaly be a nearly complete rewrite. Of course you can reuse the HTML and perhaps the page-generating code, but all of the "business logic" needs to be rewritten pretty much from scratch, as Mailman 2 has direct access to list configurations, but in Mailman 3 you need to talk REST.

I'm not sure this would be easier to install, although the typical installation / configuration problems might be more familiar to Mailman 2 users.

On 9/17/20 6:54 AM, Matthew Pounsett wrote:

If someone was going to undertake a rewrite of Postorius, using a different web development framework (e.g. Flask, but pretty much anything that isn't Django) would at least remove one major moving part from the install process.

I have said multiple times that Postorius and HyperKitty are just examples and are part of Mailman 3 because we need something and that's what we've got, and also that efforts to port Mailman 2.1 to Python 3 or add new features to Mailman 2.1 would be better spent building a lightweight (e.g. Flask based) web UI to manage Mailman 3 via its REST API.

This is exactly the motivation for the separation of the core engine from the web UI in Mailman 3.

Brian has actually done this with Affinity and Empathy, but because of his legitimate business interests, these are only available via his hosting services.

I would welcome and support anyone who wants to develop a lightweight, pythonic web UI for Mailman 3 list management and/or archiving and make it available to the community.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 9/17/20 7:20 AM, Matthew Pounsett wrote:

Yep. Sorry, that wasn't meant to sound like criticism ...

And it wasn't taken as such. I'm only trying to reinforce the idea that there are opportunities for making a different MM 3 web UI that would be less complex to install, and working on that would be a valuable and worthwhile effort.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 9/17/20 7:36 AM, Jim Popovitch via Mailman-Users wrote:

Here's my POV, if mm2 can (and it appears to me that it can somewhat easily) be fixed to use py3 then all the installed bases of mm2 don't have to learn/deal/secure/test/manage/deal with a REST API and/or Flask, etc.

Or they can just continue to use Mailman 2.1 with Python 2.7, and no one needs to do anything.

What I'm trying to do is provide a painless (or, at least a less painful) path forward for all those existing Mailman sites that don't want to deal with all the same issues that are appearing over on the MM3-users list and in #mailman.

Forward to where?

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 9/17/20 8:04 AM, Jim Popovitch via Mailman-Users wrote:

On Thu, 2020-09-17 at 07:54 -0700, Mark Sapiro wrote:

...

Forward to where?

Oh the irony of you asking that question. :) If we go back a year, there were STARK warnings about the EOL of mm2. Blatant EOL warnings. To me, a "path forward" is a way past that, a continued L(ife) with something that people know, and something that meets their needs.

The EOL notices were clarified to mean "no new features" I committed to continue to fix critical bugs and security issues going forward.

If Mailman 2.1 meets their needs now, why won't it continue to do so as it is? (Aside: I still sometimes use Adobe Reader 9 for Linux on my desktop even though it has been unsupported and unavailable from Adobe for years.)

Flipping the coin around, make the actual written case, an "elevator pitch" if you will, for some entity like NANOG or MAILOP to migrate to mm3 this weekend. Let's see what that looks like.

I'm not sure what the point of this is. According to <https://www.mailop.org/about/>, MAILOP is already on Mailman 3.

It appears NANOG has only 3 public Mailman 2.1 lists and only one has archives pre-dating MM 2.1 which could require attention before importing to HyperKitty. So list migration via mailman import21 and django-admin hyperkitty_import should be straightforward.

I guess you are saying that step 1, "First install Mailman 3" would be the sticking point, but this is the same whether you are NANOG or mail.python.org or tiny site with one list, and it has been accomplished multiple times by multiple people. I've documented my experience at <https://wiki.list.org/x/17891998>. Brian's take is at <https://wiki.list.org/x/17892066>.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Hello Phil Stracchino. On Thu, 17 Sep 2020 12:37:08 -0400, you wrote:

.. Except for the part where it requires me to keep Python 2 installed beyond its second, extended, we absolutely mean it this time, no more extensions, declared EOL.

It's not that I need anything Mailman 2 doesn't do. (Except run on Python 3.) It's that I need Python 2 to be gone, dead and buried with a fork stuck in it. I'm just waiting for Gentoo's Mailman 3 ebuild to be flagged stable.

I am in no way a programmer - but as I understand it, Python 2 can live alongside Python 3 without any problems.

The EOL declaration for Python 2 does NOT mean that Python 2 will stop working on the date the publishers announced. There will just be no improvements. And as long as there are no obvious security holes in Python 2, it is absolutely not necessary to retire it on any machine.

I am administering some mailing lists which run on MM2 / cPanel, and they work. I have no access to that machine other than via cPanel, and it is in most cases sufficient. The question of Python 2 yes or no is up to the provider.

If you absolutely want to get rid of Python 2, either use Mailman 3, or another mailing list manager.

There are some other mailing list managers available - some for free, some for money. I can propose 2 of them here, you mey find others which may work for you. I am also operating some mailing lists privately, they don’t use Mailman. They use CommuniGate Pro in the "community edition" (free version with limited number of mail and other users, but unlimited number of mailing lists and mailing list subscribers). This runs on an older Mac mini in my basement - CGPro is also available for Windows, Linux, etc. - <https://communigate.com/>

And there is Sympa, a mailing list manager created by people from French universities, see <https://en.wikipedia.org/wiki/Sympa> and <https://www.sympa.org/>

Christian

-- Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)
Hilfe fuer Strassenkinder in Ghana: http://www.chance-for-children.org

Hello Brian Carpenter. On Thu, 17 Sep 2020 14:20:06 -0400, you wrote:

I am sure Christian also meant to include me in their list of other choices: https://harmonylists.com. At least I still offer Mailman 3 howbeit as a SaaS provider and not encourage a fellow mailman user on a mailman user list to move away from using mailman.

Of course I do not want do move anyone away from Mailman. If Phil absolutely wants to retire Python 2 on his machine(s), he should either use MM3 or any other products. And I just did not think of your services when I wrote my reply to him. Good that you mentioned them.

Christian

-- Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)
Hilfe fuer Strassenkinder in Ghana: https://www.chance-for-children.org

On 9/17/2020 3:59 PM, Phil Stracchino wrote:

... The writing has been on the wall for Python2 for nearly ten years. The EOL date has already been extended five years. It's time to let it go.

The big concern du jour in science community is: can you take your scripts from 10 years ago and re-run them, and will you get the same groundbreaking result that you published back then if so. That's the main motivation for singularity, among other things.

So no: you can't let it go. You can freeze-dry it in a container, and nobody will probably ever try to reproduce that old junk, but if you do "let it go" consider this: the next vaccine that gets injected in your bloodstream may have originated with a trivial bug in someone's 10yo python script, and the only way you find out is when you die in horrible pain.

Dima

Christian F Buser via Mailman-Users writes:

I am in no way a programmer - but as I understand it, Python 2 can live alongside Python 3 without any problems.

True.

The EOL declaration for Python 2 does NOT mean that Python 2 will stop working on the date the publishers announced. There will just be no improvements. And as long as there are no obvious security holes in Python 2, it is absolutely not necessary to retire it on any machine.

As far as I know there are already obvious security holes in Python 2 if you need to use TLS, especially on Mac. Python 2 is not up to current security recommendations with respect to SSL and TLS versions, and I suspect not with respect to other basic crypto. I don't think it's hard to configure those version exclusions, but it doesn't come out of the box that way. And on Mac you've got the mess that is an Apple-specific TLS API that Python doesn't have a wrapper for last I heard (it uses an bundled version of OpenSSL instead if you configure it to support TLS).

I'm pretty sure that at least for now I[1] can configure a system to run Mailman 2 so that none of the above matters (eg, have the web server and MTA speak TLS so that Mailman doesn't have to), but I'm not confident that will last for very long.

Footnotes: [1] Or any reasonably up-to-date sysadmin.

On 9/19/20 9:50 AM, Matthew Pounsett wrote:

I'm probably going to regret getting involved in this conversation, but ...

On Sat, 19 Sep 2020 at 08:48, Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

...

I'm pretty sure that at least for now I[1] can configure a system to run Mailman 2 so that none of the above matters (eg, have the web server and MTA speak TLS so that Mailman doesn't have to), but I'm not confident that will last for very long.

I'm pretty sure that's pure FUD. I'm not the expert on mailman that most of you are, but I can think of no reason for mailman itself to ever speak HTTP or SMTP, and therefore no reason for it to need to do TLS. I'd be very surprised at anyone running a mailman setup where there wasn't a web server and an MTA sitting between mailman and the rest of the Internet. Am I wrong about that?

I think that was exactly Steve's point.

Does mailman even include its own web server? I didn't think it did.

No, it doesn't. It does however do SMTP to an MTA that isn't necessarily on localhost, so TLS can be an issue there.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

I wrote:

...

...

...

I'm pretty sure that at least for now I[1] can configure a system to run Mailman 2 so that none of the above matters

"None of the above" includes other crypto.

...

...

I'm pretty sure that's pure FUD.

I do not agree. Besides being able to talk SMTP (and some people have used it, though I'm sure it's very few nowadays), Mailman 2 talks DNS (for DMARC) although I am not sure it can deal with secure DNS (in fact, I'm not sure anyone can ;-). DNS over HTTPS (DOH) is coming, which implies TLS. Mailman 3's ARC handler has to do both encryption and decryption for ARC and decryption for DKIM, and that would be fairly easy to port (I'm pretty sure the underlying libraries are 2/3 compatible). (Ports are fair game because we're talking "future", and I imagine ARC support is something Jim Popovitch would like to have.) Any secure version of those protocols that Mailman 2 doesn't have could Mailman unusable if some important partner decides to require it.

I'm sure I'm missing stuff, too. So no, it may not be more likely than not (given current status of "EOL"), but it's not pure FUD. And if the "reopen Mailman 2 for features" crowd has its way, the likelihood goes up IMO (because I don't think they're likely to succeed in getting a sufficiently stable port of Mailman 2 to Python 3).

Steve

Jim Popovitch via Mailman-Users writes:

You're on the Mailman Cabal

Yes. That means that the Mailman Cabal enjoys working with me and values what I do, and that's all it means. By the way, I'm not sure why you keep mentioning the Mailman Cabal, There Is No Cabal. ;-)

...

I imagine ARC support is something Jim Popovitch would like to have.

You imagine wrong.

OK, so you don't believe in providing features that other users want.

Let's be realistic, nobody says "I'm gonna ditch my MTA and replace it with Mailman",

True. What they do is to configure Mailman to perform functions that we, like everybody else, recommend be implemented in the MTA (such as spam filtering and ARC). That is the day-to-day reality of supporting Mailman.

TINC-ly y'rs

Steve

On 9/20/20 7:40 AM, Stephen J. Turnbull wrote:

Yes. That means that the Mailman Cabal enjoys working with me and values what I do, and that's all it means. By the way, I'm not sure why you keep mentioning the Mailman Cabal, There Is No Cabal. ;-)

Technically, mailman-cabal is just the name of a mailing list, nothing more. Officially, the group is the Mailman Steering Committee.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 19 Sep 2020, at 8:39, Stephen J. Turnbull wrote:

As far as I know there are already obvious security holes in Python 2 if you need to use TLS, especially on Mac. Python 2 is not up to current security recommendations with respect to SSL and TLS versions, and I suspect not with respect to other basic crypto. I don't think it's hard to configure those version exclusions, but it doesn't come out of the box that way. And on Mac you've got the mess that is an Apple-specific TLS API that Python doesn't have a wrapper for last I heard (it uses an bundled version of OpenSSL instead if you configure it to support TLS).

That's a pretty obscure edge case.

Most people who use *current* MM2 on Mac do so via Homebrew or MacPorts builds, both of which also bring in a current OpenSSL by default. If one insists on building from scratch using the system "openssl," then on any recent system it is actually a recent and reasonably safe LibreSSL.

-- Bill Cole bill@scconsult.com or billcole@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently)

On 9/17/20 1:45 PM, Jim Popovitch via Mailman-Users wrote:

That's kind of my point. mm2 works for me and my use, I'd much rather prefer to keep it working than to rip it out and replace it, including installed and maintaining a database, a framework, a new setup of custom admin scripts unique to my setup, etc. No one has sold me on mm3 yet.

It's because you don't want to be sold. But I will say this, what you want as a list owner, and what your list members want are two different things. They may line up and they may not. But I suspect many list owners are watching their mm2 lists shrink either in membership size or posting activity. Communication behavior changes. Social media has had a tremendous impact on how communications work on the web. Integrations are very important to a lot of groups. None of these things are possible with Mailman 2. Mailman 2 is inflexible as your position to not be swayed to use Mailman 3.

Also your above comments show your unjustified bias against Mailman 3: "you have to do so many things to use Mailman 3". No you don't. I think the real culprit is your custom admin scripts that you are using to make up for whatever shortcomings you found with MM2.  You don't want to go through the task of getting them to work with Mailman 3. Perhaps you can't. So at least that is a valid point for wanting to stick with MM2. However that is not the fault of Mailman 3.

...

I'm not sure what the point of this is. According to <https://www.mailop.org/about/>;, MAILOP is already on Mailman 3. They are not, (i'd guess most likely due to overly optimistic views on how easy a migration to mm3 would be, perhaps they needed a bigger server or had to hire a database guy, who really knows). What i do know is that, from a post yesterday, they are still using an old Mailman version:

Date: Wed, 16 Sep 2020 08:37:43 -0500 Subject: Re: [mailop] Spam using bit.ly link shorteners, this time via Outlook X-BeenThere:mailop@mailop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: For mail operators <mailop.mailop.org>

I'd email Simon to ask why the discrepancy, but he's already alluded to it a few times on their list. Note: he originally planned to started moving mailop.org to mm3 last December, so he's had plenty of time.

Please let Simon know I can install Mailman 3 and migrate his list to Mailman 3 within a day.

...

It appears NANOG has only 3 public Mailman 2.1 lists and only one has archives pre-dating MM 2.1 which could require attention before importing to HyperKitty. So list migration via mailman import21 and django-admin hyperkitty_import should be straightforward.

I guess you are saying that step 1, "First install Mailman 3" would be the sticking point, but this is the same whether you are NANOG or mail.python.org or tiny site with one list, and it has been accomplished multiple times by multiple people. I've documented my experience at <https://wiki.list.org/x/17891998>;. Brian's take is at <https://wiki.list.org/x/17892066>;.

I've read both of those links in the past, and honestly that is good detail to have. What I was looking for in an "elevator pitch" is a 30 second statement on what benefit someone would have by moving to mm3. Given the time and effort (big or small) why should anyone move to mm3 if their mm2 installation still works and functions fine? There are people here saying "move to mm3 now!!, etc.", but what's the selling point?

-Jim P.

I have been posting those selling points frequently. But you are *inflexible* in your insistence in using MM2.

I will give you a 3 second selling point: *flexibility*, choices, future new features, searchable archives, a growing community of users, etc.

-- Brian Carpenter Harmonylists.com Emwd.com

On 9/17/20 2:27 PM, Jim Popovitch via Mailman-Users wrote:

On Thu, 2020-09-17 at 14:15 -0400, Brian Carpenter wrote: Absolutely not. I'm intrigued by the idea of mailman-core (1/3 of mm3) with a lightweight web-based GUI in front of it. But, to date, that doesn't exist. I also don't see the need for a db and api with a MLM, but I do see value in those things.

No just a need for a 15 year out-dated user interface and a MLM that requires an EOL version of Python. Otherwise Mailman 3 can behave in the same manner as Mailman 2. The installation of Mailman 3 takes an hour. That includes OS, web server, database, MTA and python 3. All of the complexity you continue to gripe about is, to use your word, fud.

That's just FUD. Don't take offense because I haven't taken you up on your mm3 work around(s). I have mm3 installs, but they are not what my users want.

There it is again. A use of a word meant to imply something negative. Affinity and Empathy are not "workarounds". They are modern interfaces that I developed because I host MANY list owners with all kinds of requirements. I also wanted something to set apart myself from other potential competitors. I am still using Postorius and Hyperkitty to for Mailman 3 hosting clients. They are still fine to work with.

So your users don't want to use a MLM that works just like Mailman 2? Mailman 3 can just be that but the potential to be more is there, a potential that Mailman 2 does not have.

Again, you're the guy who had to pay someone else to make 2/3rds of Mailman 3 work for you.

Again a disingenuous remark. You pull the same bs with Stephen all the time. Mailman 3 works fine apart from Affinity/Empathy. I accomplished a bold marketing and brand move with those two applications. You wouldn't understand that. I am no longer on the same playing field with budget hosts. I have set my company apart from them. Why because Mailman 3 gave me the ability to do that. Mailman 2 did not.

My "custom scripts" are cron+bash scripts to send monthly mailman reports out to admins. Hardly anything that can't be re-worked anywhere else, but why?

Then why bring them up as a reason to not use MM3?

...

Please let Simon know I can install Mailman 3 and migrate his list to Mailman 3 within a day. I won't be your salesman.

Yet you have been in the past. Jimmy, did I offend you???

I hope you one day see how ridiculous that sounds as an elevator pitch.

Not anymore ridiculous as your proposals to work harder to keep an EOL MLM application alive when its replacement is alive and well.

-- Brian Carpenter Harmonylists.com Emwd.com

On 9/17/20 10:36 AM, Jim Popovitch via Mailman-Users wrote:

Would it though? Is that conjecture or based on available data that can be analyzed? Here's my POV, if mm2 can (and it appears to me that it can somewhat easily) be fixed to use py3 then all the installed bases of mm2 don't have to learn/deal/secure/test/manage/deal with a REST API and/or Flask, etc. All those current mm2 admins get to continue life as they normally do. They save a weekend (or a month in some cases) and some even save some $$, by not having to significantly change their Mailman installation or server size, etc. What I'm trying to do is provide a painless (or, at least a less painful) path forward for all those existing Mailman sites that don't want to deal with all the same issues that are appearing over on the MM3-users list and in #mailman.

I am seeing issues with MM2 on this list. Issues always exist with software applications so please stop using that as an argument against the adoption of Mailman 3. It's disingenuous.

Django is complex so moving away from it would reduce the complexity of a Mailman 3 installation procedure and maintenance. I manage dozens of mailman 2 and mailman 3 servers. When it comes to maintenance and support issues not much of a difference between the two. I will tell you this though, migrating a mm2 list to mm3 is easy and effective.

See, this discussion of changing interfaces for Mailman 3 itself demonstrates the flexibility of Mailman 3. A flexibility Mailman 2 will never see. The needs of list admins (and let's not forget list members) do change and they should as evolution of email discourse continues to change. Mailman 3 is in a better position to meet the needs of list admins (and let's not forget list members) far better than Mailman 2.

Personally having the ability to communicate with a list using email and a lightweight forum at the same time is a great thing. In fact, I think it is the future as list members will grow to like the flexibility. Let's not forget the way archives become instantly more useful with an include search feature in a Mailman 3 installation.

-- Brian Carpenter Harmonylists.com Emwd.com

On 9/17/2020 9:24 AM, Brian Carpenter wrote:

FYI, here is a decent comparison of Django vs Flask:

https://hackr.io/blog/flask-vs-django

In the article, this was said:

"Django is suited for bigger projects that need a lot of functionality. For simpler projects, the features might be an overdose"

Meh. The real deal is Django is the kind of framework that makes you program for the framework. Flask gives you everything you need and does not force you to touch anything you don't -- not that there is a lot of the latter in it.

Django is suited for the projects where the goal is write an application in django ecosystem. For everything else, it is not.

Dima

Jim Popovitch via Mailman-Users writes:

Wait, so you do want to continue to support mm2 users, but you don't want to support them in any fashion if someone else other than you and Mark manages just the new features?

That's right.

Currently Mark and I have a tolerable balance between the burden of work that is intrinsically not very rewarding, the value that we get from serving our users, and the knowledge that the burden is steadily decreasing. That decrease depends on the feature freeze.

You propose to remove the freeze, and indeed suggest that Mailman 2 even has a long-term growth story via rewriting in Python 3. I am not signed up for a slower decline in the user base, let alone growth, and I think it's safe to say neither is Mark.

Here's the problem.

I think the genuine problem here is that it's a 2 man show when it should be a much larger body.

You're right. If we're going to reopen the Mailman 2 branch to new features, there should be a much larger body. So where is it? Mark and I are not special. We're merely here every day, we have acquired a lot of knowledge about common issues, and we dig into the code or the user's configuration when that's needed to solve a problem. You don't need to have a title, an @mailman email address, or a commit bit to do any of that.

You just do it.

It's *easy* to learn to support users, at least the relatively sophisticated, often service-oriented admins we see on most days. So where are the folks who "just do it" and show day-to-day attachment to supporting other users?

Bottom line: When do we get to retire? What happens to our *users* when we do? Eventually (ie, within 3 years or so) that *is* going to happen. What are you going to do for our users?

"Manage just the new features" sounds like a terrible deal for the vast majority of admins and subscribers, and a very bad look for GNU Mailman.

Jim Popovitch via Mailman-Users writes:

On Thu, 2020-09-17 at 02:34 +0900, Stephen J. Turnbull wrote:

...

You don't need to have a title, an @mailman email address, or a commit bit to do any of that.

You just do it.

Exactly! But that is not really what this convo is all about.

No, that is *all* this conversation is about. You need to persuade us to give you what you want. If you don't speak to our interests, you won't get it.

You keep taking it into the "end user support" arena, I'm focused on product preservation.

I care very little about product preservation for Mailman 2 (it's complete subordinate to user service in the sense that it would be a nice to have if there's zero risk to user support), and you need *nothing* from us to do it, anyway.

Pragmatically, users are *all* I care about in the Mailman 2 world. And I'm quite sure that's what the rest of GNU Mailman (the software development project) thinks, too. Note well: I am not their elected representative, but I believe my statements are generally representative of their beliefs about the user base and their values. If you think otherwise, get in touch with them off list, since they aren't posting that I'm full of nonsense on list (ie, maybe they're just not listening here).

There are multiple roles, as you well know, why do you feel I need to fit in the role you define for me?

You don't need to fit into any role in the Mailman project. You have the code, you have access to Launchpad or Github or Gitlab or SourceForge, and you have and will have access to this mailing list.

But if you don't care about users, you're not part of the team. You're a lone ranger.

Who's users? ;-)

The Mailman Project's users, and in particular subscribers and admins of Mailman 2 sites and lists.

I think, based on this thread, you are going to have a really tough time ever retiring from Mailman.

From "Mailman"? Not even envisioned at present, except in the sense that I'm old enough to be aware of my own impending death being closer to me than my birth.

From *Mailman 2*? No problem at all. This is not my first rodeo, my friend. You clearly do not understand what I've been saying about the costs and benefits of user support and why GNU Mailman has chosen the development and user support strategies we have.

I'm not saying you should agree. Certainly not that you should abandon your own interests. But you seem to have a completely unrealistic idea of how things work in open source and how you could get at least some of what you want in this particular case.

...

"Manage just the new features" sounds like a terrible deal for the vast majority of admins and subscribers, and a very bad look for GNU Mailman.

Let GNU Mailman, the FSF, and the Mailman community decide that and don't prevent them from deciding that.

Have a clue, Jim. Really. Abhilash, Mark, I, and several others *are* GNU Mailman -- there's nothing else it *could* be. The FSF has nothing to do with decisions about what code we distribute, that's not what GNU is about. The Mailman community is *not* going to be part of the decision-making process, except that a small, unrepresentative sample of individual community members post here, and GNU Mailman is listening to them. And in fact, there will not even be a decision in some sense. That is, we could lift the feature freeze at any future date, and then we could reverse that decision afterward.

As for me preventing anything, I can't prevent anything -- if it's at all a close call, Abhilash will decide -- and I am not trying to do so. I am *advocating* that

1. the current feature freeze is, on balance, *good* for the community as a whole even though there's a very vocal group (I take it on faith that you're not the only one ;-) that wants the freeze lifted, and

2. that lifting the freeze *as proposed on this list* is *not* in the interest of GNU Mailman or the community

and I am stating that

3. due to my own preferences and constraints, I will retire from Mailman 2 support if I don't get credible assurances that Mark and I will get substantial help with user support to offset the likely increase in needs, and to ensure that user support is maintained at high levels even as we reduce our commitments as currently planned.

I'm done, Jim.

On 8/26/20 7:02 PM, Jim Popovitch via Mailman-Users wrote:

I'm not sure where you think money comes into this, unless you are admitting that moving to mm3 requires expensive consulting contracts. I've turned down 2 large orgs that had trouble migrating from mm2 to mm3 and needed a 3rd party to bail them out. Brian, I recall referring one of them to you. So, I guess, money does come into play. Fear is another interesting choice of words. Do you think that the fear might be due to someone repeating over and over that this open source project is dead and will only be in maintenance mode (life support?) going forward?

Because the main reason why Mailman 2 has seen the popular use that it does is because of budget hosts that offered cPanel and Plesk environments. Both of them included Mailman 2 with their packages. I do know some hosting control panels are starting to drop support for Mailman 2 and that will continue to grow. I personally don't think Mailman 3 will see as large of an adoption rate as Mailman 2. That is because cheap hosting companies are not interested in quality but quantity. cPanel will probably never adopt Mailman 3. Dreamhost said no to it and will keep Mailman 2 for now. Why? Because Mailman 3 requires a more complex environment. However, my opinion, most well developed apps do. So SaaS providers such as myself will play a more important role in the propagation of Mailman 3. That's not a bad thing. At least Mailman 3 will have providers who will provide expert and conscientious support of Mailman 3 than some of these budget hosts (looking at you A2).

I think what prevents folks like you and Carl, ultimately, is fear of the unknown. Mailman 3 does not require expensive consulting contracts. I made a $150 bucks from your referral. That doesn't break no one's budget. Also I would appreciate if you keep our private conversations off of a public mailing list.

Mark is simply saying it doesn't make sent to continue to build up a retired application (MM2) and instead focus their limited resources on a young stallion called MM3. There is nothing wrong with that. Go to someone else for the development of MM2.

Let's recognize that mm3 has been around for 10 years, and during that time mm2 has been expanded and enhanced over and over. The difference now is that the gatekeeper who was doing that wants to move on, and should have the right and support to move on.

...

Well fine, then let those hosts take on the > responsibility of keeping Mailman 2 up to date. That is what open source > is all about.

That, *that* ^^^, is my point. I want to take that on, I want to work with contributors to commit their vetted and tested patches into the mm2 branch, I've basically been told to go somewhere else to do it. I think who/m ever takes it on should be part of the Mailman Team. There is absolutely no reason against, and there are certainly several examples for, having 2 or more active development branches in an open source (or closed source for that matter) project.

So go to cPanel forums to request that or Dreamhost, or others. I am pretty sure you will not like the answer you will get from them. Why wouldn't you just spend your efforts to migrate to Mailman 3? I just don't see the logic in your efforts here.

I didn't like Postorius or Hyperkitty (still don't, sorry Mark and Abs). So due to that beautiful REST api, I made my own path. At the end of the day, its still Mailman 3 that I am using. Modern web development offers so much choices and potentials these days for users. It's just sad that Mailman 2 will never see those choices and potentials because it just doesn't have the foundation to do so. It is dead in the water. But it is resurrected in Mailman 3.

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

Jim Popovitch via Mailman-Users writes:

That, *that* ^^^, is my point. I want to take that on, I want to work with contributors to commit their vetted and tested patches into the mm2 branch, I've basically been told to go somewhere else to do it.

You have not been told to go elsewhere. You've been told you're free to use some of our resources, and I would be happy to include the Mailman 2 repo among them (it's not mine to give but I would support it). We can and should cooperate in many ways, I believe.

But: your goals are nearly disjoint from ours[1], and the work you propose to do far more limited. The teams will probably be completely disjoint, and there probably will be no synergies between them because of the divergence of the development platforms and the architectures of the applications. I want those facts recognized by both teams and made clear to Mailman users, and I suspect so will other members of current Mailman core team.

If it turns out that the teams intersect substantially, and/or there are development or support synergies involved, then I would reconsider my position.

I think who/m ever takes it on should be part of the Mailman Team.

Given the facts stated above, I don't see why.

You *won't* be part of the Mailman small-t team that I'm on, any more than Brian is part of my team while he develops Affinity.

You're part of the Mailman community, as is Affinity, and as is Brian in many roles as well as Affinity. I can speak for Mailman core in saying we're happy to have you both. All three projects are rooted in Mailman 2 (and before that Mailman 1!), and there's a future for all three. It's just that the future for Mailman 3 and Affinity is growth, while the future for Mailman 2 is retirement. I see your role as (unavoidably) making that retirement a very graceful one, and perhaps delaying it by a bit. But there's no need for coordination with the forward-looking part of the problem, and several reasons against.

There is absolutely no reason against, and there are certainly several examples for, having 2 or more active development branches in an open source (or closed source for that matter) project.

Jim, you may not know better, but I do. *I've done that*, in XEmacs (I have the T-shirt! as project lead) and in Python (as gadfly and onlooker). It's painful and distracting for the core development team, so there are two reasons not to do it for you.

The question for you is what benefit there is to anyone in having Mailman 2 maintenance inside the Mailman Project going forward. The Mailman Project certainly doesn't want to encourage new installations of Mailman 2. Encouraging new use of obsolete[2] code definitely was the effect of maintaining multiple branches of XEmacs and Python inside their respective projects.

Footnotes: [1] We share wanting Mailman 2 users to be happy. But as Brian has forcefully advocated, we believe that in the not-so-long run, the path to happiness for Mailman 2 users is migration to Mailman 3.

[2] In the sense of pragmatically unmaintainable in the long run.

On 8/27/20 3:41 AM, Jim Popovitch via Mailman-Users wrote:

On Thu, 2020-08-27 at 17:41 +0900, Stephen J. Turnbull wrote:

...

The question for you is what benefit there is to anyone in having Mailman 2 maintenance inside the Mailman Project going forward.

You mean inside the Mailman3 Project at mailman3.org? None.

...

The Mailman Project certainly doesn't want to encourage new installations of Mailman 2.

Again, Do you mean the Mailman3 Project at mailman3.org and on the MM3- org mailinglists? If so, fine, move on.

I think Steve is referring to the GNU-Mailman project which is the group of people, always small and continuously evolving, starting with John Viega, who've been responsible for the development and maintenance of Mailman since it's inception.

I'm still not clear on what you (Jim) are really wanting to do. I may be wrong on this, but I don't see any distros picking up new versions of Mailman 2.1 unless they come from some 'official' source and so far, the GNU-Mailman project is the only such source. I'm not even sure that any distros are planning to package Mailman 2.1.34.

I don't think Steve or I is being 'proprietary' about Mailman per se, but we are proprietary about the GNU-Mailman project, so the question is do Jim and possibly others become part of the GNU-Mailman project and continue to maintain the 2.1 branch on Launchpad or wherever and make 'official' releases, or do they fork the project and hope that their fork becomes the accepted source for Mailman 2.1.x.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 8/27/2020 9:54 AM, Phil Stracchino wrote:

Currently there is no active ebuild for mailman in Gentoo. 2.1.33 has been masked, there is no 2.1.34, and 3.3.0 and 3.3.1 exist but have not yet been marked stable or unmasked.

FWIW, FreeBSD 12.1-RELEASE amd64 has 2.1.34 in both the pkg repo and the ports tree. I do not see a MM3 package but didn't look too closely.

z!

Phil Stracchino <phils@caerllewys.net> writes:

On 2020-08-27 12:30, Mark Sapiro wrote:

...

I'm still not clear on what you (Jim) are really wanting to do. I may be wrong on this, but I don't see any distros picking up new versions of Mailman 2.1 unless they come from some 'official' source and so far, the GNU-Mailman project is the only such source. I'm not even sure that any distros are planning to package Mailman 2.1.34.

Currently there is no active ebuild for mailman in Gentoo. 2.1.33 has been masked, there is no 2.1.34, and 3.3.0 and 3.3.1 exist but have not yet been marked stable or unmasked. The process of stabilizing a mailman3 ebuild is ongoing and I've been monitoring it.

mailman-2.1.34 is avaialble from FreeBSD ports (and probably from pkg as well). Mailman 3 isn't yet.

--

Keith Seyffarth mailto:weif@weif.net https://www.weif.net/ - Home of the First Tank Guide! https://www.rpgcalendar.net/ - the Montana Role-Playing Calendar

http://www.miscon.org/ - Montana's Longest Running Science Fiction Convention

On 8/26/2020 4:05 PM, Brian Carpenter wrote:

You are all looking at the wrong thing here. The real question here is why are you not wanting to move to a Mailman 3 environment? It's not hard to install anymore. It has a future. It is modern. It as a long life expectancy and, most importantly, its being supported and developed.

Python $version code has a long life expectancy? Wow. When did that happen?

Dima

On 8/26/2020 7:26 PM, Brian Carpenter wrote:

On 8/26/20 8:13 PM, Dmitri Maziuk wrote:

...

Python $version code has a long life expectancy? Wow. When did that happen?

Wonderful contribution to this conversation.

The point was that the argument about MM3 having a long life expectancy "because python 3" is not in any way, shape, or form supported by the history of the python programming language to date.

Arguing that MM3 itself is going to be supported because there's more that just Mark supporting it effectively boils down to "Mark will stop patching MM2". That's certainly possible, but maybe we should ask him instead of taking your word for it?

Dima

Dmitri Maziuk writes:

The point was that the argument about MM3 having a long life expectancy "because python 3" is not in any way, shape, or form supported by the history of the python programming language to date.

*chortle* *In Mailman's experience* Python's backward compatibility record has been an annoyance because it's *too good*. Much of the time we were officially supporting *four* 2.x versions, and it would have been *five* at times except that we were conservative about supporting the most recent release. It was almost always trivial to do so. This policy of supporting old Python versions was quite painful at times, preventing us from taking advantage of new Python features. The only 2.x backward compatibility issue I can recall that bit Mailman was the introduction of true Booleans (yeah, that long ago), and that was easy to fix. Mark can probably tell a few stories.

Although the port of Mailman 3 to Python 3 took a couple of years, after that we had a spurt of rapid development, because Python 3 is a much better environment for development of new code, and because str- is-Unicode-inside made the email package much more reliable. A lot (not all, but a lot) of bugs were simply made impossible. We don't support as many versions of Python 3 (usually 2-3) because our current Mailman 3 user population is smaller, biased toward the beta tester type, and generally more sophisticated.

Arguing that MM3 itself is going to be supported because there's more that just Mark supporting it

Beside the point, actually. There are *many* people supporting MM2 users (including me and Jim P, for two prominent examples). But the patch rate has been near zero for *years*, and has definitely *not* included many of the patches I imagine Jim would want to include.

MM3, on the other hand, not only has three more or less active developers, it also has frequent releases including new features as well as bug fixes.

effectively boils down to "Mark will stop patching MM2". That's certainly possible, but maybe we should ask him instead of taking your word for it?

"There is none so blind as he who will not see" what is in the archives of mailman-users and mailman-developers many times. Mark hasn't set a sunset date, but soon he's going to Just Say No.

On 8/27/2020 3:27 AM, Stephen J. Turnbull wrote:

Dmitri Maziuk writes:

...

The point was that the argument about MM3 having a long life expectancy "because python 3" is not in any way, shape, or form supported by the history of the python programming language to date.

*chortle* *In Mailman's experience* Python's backward compatibility record has been an annoyance because it's *too good*. Much of the time we were officially supporting *four* 2.x versions, and it would have been *five* at times except that we were conservative about supporting the most recent release. It was almost always trivial to do so. This policy of supporting old Python versions was quite painful at times, preventing us from taking advantage of new Python features.

Yes, precisely: "feechorz". My point wasn't that MM is having python compatibility problem, it was that python has compatibility problem with itself.

Although the port of Mailman 3 to Python 3 took a couple of years, after that we had a spurt of rapid development, because Python 3 is a much better environment for development of new code, and because str- is-Unicode-inside made the email package much more reliable. A lot (not all, but a lot) of bugs were simply made impossible. We don't support as many versions of Python 3 (usually 2-3) because our current Mailman 3 user population is smaller, biased toward the beta tester type, and generally more sophisticated.

Yes, exactly. I run stable infrastructure services for not Beta Tester types, I want Simple Stupid and Stable.

Beside the point, actually. There are *many* people supporting MM2 users (including me and Jim P, for two prominent examples). But the patch rate has been near zero for *years*, and has definitely *not* included many of the patches I imagine Jim would want to include. ... "There is none so blind as he who will not see" what is in the archives of mailman-users and mailman-developers many times. Mark hasn't set a sunset date, but soon he's going to Just Say No.

Well if the patch rate is near zero, then it doesn't matter anyway. And yes, I am well aware of the previous discussions on the subject, and of the need to DIY spamd.py and SpamAssassin.py and so on. I'll take that over a django instance, even containerized, any day.

Dima

On 8/26/20 10:29 PM, Chip Davis wrote:

What I don't understand is your vitriolic objection to Jim's offer. How is that any skin off your nose?  Do you see this as a zero-sum game in which every MM2 instance that doesn't "upgrade" is a threat to MM3?  If it's as superior as you claim, there should be a thunderous stampede to adopt MM3.  The bazaar will speak eloquently.  What, exactly, is the cock you have in this pit?

Bottom Line: As long as there are inexpensive cPanel hosts running Mailman 2, *I have no choice*.   So I greatly appreciate Jim's offer to pick up the burden and allow Mark to move on.

I watched for years how cheap budget hosts provided crap support for the software that they hosted. I watched Mark for years take on that extra burden of making up for their crap support because of it via the old MM2 user list.

I am sure Mark has moved on from Mailman 2, at least he has said that on numerous occasions. It is you folks that won't let him. You want to keep using MM2 and you want the developers to keep supporting it. That pressure can/does hinder the work on Mailman 3.

I really did not like Jim's comment and that set me off:

"I hate to say this, but I'm sensing an exclusivity in your and Mark's comments. Is Mailman a open source project or is it an exclusive club?"

I really don't like your comments either towards me in the quote above and the way you mis-represented Mailman 3 in your reply to Odhiambo. I offer shared and dedicated environments for Mailman 3 and none of my clients have to worry about the complexities of Mailman 3 at all. I didn't like the way Carl quoted an old piece of information and when he was corrected, proceeded to dig in his heels. I didn't like a lurker who never posted to any Mailman list before, suddenly come out of the woodwork to mock me on the use of "long life"

By the way there is always a choice. I have been offering Mailman 3 shared list hosting for almost 2 years now. It's that few extra dollars a month that is a budget breakers for cheap host users. Oh well.

I know now that none of you have any intention of using or supporting Mailman 3. My pro MM3 comments have been mocked, ignored, and discarded. Ok. Fine. I think none of you has shown any respect or appreciation in the work that has been done to propel the Mailman project into the modern web development world. That shows that all you really care about is your wallets and how much you may have to work to move your lists to a Mailman 3 environment. This isn't about Mailman at all. It's about how can have a mailing list and stay using a cheap budget host. For Jim? Well I don't really care why he doesn't use Mailman 3. I think his claims about wanting to support Mailman is a joke. If he really wanted to support the Mailman project, then he would throw his weight behind Mailman 3.

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

OMG! Shut up!

-----Original Message----- From: Chip Davis <chip@aresti.com> Sent: Wednesday, August 26, 2020 8:47 PM To: mailman-users@python.org Subject: [Mailman-Users] Re: mailman v2.x

OK Brian, so your answers to my questions are:

"I have a profit motive to encourage MM3 adoption" ... and ... "I'm baffled that all the people on the Mailman *2* discussion list are not scrambling to adopt MM3"

Have I got that about right?

For the record, I have enjoyed exemplary support from all three of my "cheap budget hosts" whenever I've had an issue. And yes, one of them is A2.

I will sign off of this thread by pointing out that your first contribution to it was a reply to my posting supporting Jim's generous offer to help support the MM2 community, in which you stridently attempted to convince us to convert over to MM3 instead.

Respectfully, we decline.

-Chip-

On 8/26/2020 11:17 PM, Brian Carpenter wrote:

On 8/26/20 10:29 PM, Chip Davis wrote:

...

What I don't understand is your vitriolic objection to Jim's offer. How is that any skin off your nose? Do you see this as a zero-sum game in which every MM2 instance that doesn't "upgrade" is a threat to MM3? If it's as superior as you claim, there should be a thunderous stampede to adopt MM3. The bazaar will speak eloquently.
What, exactly, is the cock you have in this pit?

Bottom Line: As long as there are inexpensive cPanel hosts running Mailman 2, *I have no choice*. So I greatly appreciate Jim's offer to pick up the burden and allow Mark to move on.

I watched for years how cheap budget hosts provided crap support for the software that they hosted. I watched Mark for years take on that extra burden of making up for their crap support because of it via the old MM2 user list.

I am sure Mark has moved on from Mailman 2, at least he has said that on numerous occasions. It is you folks that won't let him. You want to keep using MM2 and you want the developers to keep supporting it. That pressure can/does hinder the work on Mailman 3.

I really did not like Jim's comment and that set me off:

"I hate to say this, but I'm sensing an exclusivity in your and Mark's comments. Is Mailman a open source project or is it an exclusive club?"

I really don't like your comments either towards me in the quote above and the way you mis-represented Mailman 3 in your reply to Odhiambo. I offer shared and dedicated environments for Mailman 3 and none of my clients have to worry about the complexities of Mailman 3 at all. I didn't like the way Carl quoted an old piece of information and when he was corrected, proceeded to dig in his heels. I didn't like a lurker who never posted to any Mailman list before, suddenly come out of the woodwork to mock me on the use of "long life"

By the way there is always a choice. I have been offering Mailman 3 shared list hosting for almost 2 years now. It's that few extra dollars a month that is a budget breakers for cheap host users. Oh well.

I know now that none of you have any intention of using or supporting Mailman 3. My pro MM3 comments have been mocked, ignored, and discarded. Ok. Fine. I think none of you has shown any respect or appreciation in the work that has been done to propel the Mailman project into the modern web development world. That shows that all you really care about is your wallets and how much you may have to work to move your lists to a Mailman 3 environment. This isn't about Mailman at all. It's about how can have a mailing list and stay using a cheap budget host. For Jim? Well I don't really care why he doesn't use Mailman 3. I think his claims about wanting to support Mailman is a joke. If he really wanted to support the Mailman project, then he would throw his weight behind Mailman 3.

Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-leave@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/

On Wed, 2020-08-26 at 23:17 -0400, Brian Carpenter wrote:

I am sure Mark has moved on from Mailman 2, at least he has said that on numerous occasions. It is you folks that won't let him.

There is sooo much to respond to, but in order to stay on focus... Brian, you fail to identify the problem, in fact you mischaracterized it. Mark is essentially gatekeeping. He is saying that he wants to continue to control security maintenance of mm2 but he wants any other feature development to be under a different umbrella away from his gatekeeping.

You want to keep using MM2 and you want the developers to keep supporting it.

Absolutely not. We see life in MM2 and want the gatekeepers out of the way.

That pressure can/does hinder the work on Mailman 3.

That is imaginary or self-contrived pressure.

-Jim P.

On Thu, 2020-08-27 at 10:05 -0700, Mark Sapiro wrote:

On 8/27/20 3:29 AM, Jim Popovitch via Mailman-Users wrote:

...

There is sooo much to respond to, but in order to stay on focus... Brian, you fail to identify the problem, in fact you mischaracterized it. Mark is essentially gatekeeping. He is saying that he wants to continue to control security maintenance of mm2 but he wants any other feature development to be under a different umbrella away from his gatekeeping.

I am the gatekeeper because the current Mailman 2.1 branch belongs to the GNU-Mailman project and I am the only member of that project who is doing anything with updating/releasing Mailman 2.1. If I weren't there, the gate would be locked.

The phrasing of "the current Mailman 2.1 branch belongs to the GNU- Mailman project" seems odd.

...

Absolutely not. We see life in MM2 and want the gatekeepers out of the way.

We've had this discussion at <https://code.launchpad.net/~jks/mailman/hcaptcha/+merge/389691>;. I have told you what you need to do to get commit permission to the branch at <https://code.launchpad.net/~mailman-coders/mailman/2.1>;, and I assume that your initial post in this thread was an effort to get others to join you in this. I am sure that I and the other members of the GNU-Mailman project will give serious consideration to anything you propose, but we haven't seen a proposal yet.

To be honest, I felt your post here https://code.launchpad.net/~jks/mailman/hcaptcha/+merge/389691/comments/1024... was a bit over the top. You seem to have gone on and on about listing all the possible things that I would need access to, as though it would be such an impossibility for the Cabal to approve.

Please stop painting me as an obstructionist who wants to kill Mailman 2.1. I do not think that's a fair characterization.

I'm not here to judge you, I think your position on Mailman 2.1 is very clear, and I think my good and thankful opinion of you is well understood by the readers of this email.

-Jim P.

On 2020-08-27 13:15, Rich Kulawiec wrote:

3. Captchas are a worst practice in security and should never be used. They can be and are defeated at will by any adversary who wants to trouble themselves to do so. They're also user-hostile. There are much better methods available for protecting Mailman instances from abusers.

I've said for some time that traditional captchas are by now almost a REVERSE test. Ability to solve them should be taken as stronger evidence that you are a bot than that you are a human, because bots are better at solving them than humans are.

Image-style captchas like reCaptcha are better, but they too have a shocking oversight: They do not scale well on increasingly-ubiquitous high-resolution displays. I'm currently using a 32" 4K monitor, and even after zooming the page as far as I can, I still sometimes have to resort to a magnifying glass to be certain whether I'm seeing a specified object somewhere in the background of one of the images.

-- Phil Stracchino Babylon Communications phils@caerllewys.net phil@co.ordinate.org Landline: +1.603.293.8485 Mobile: +1.603.998.6958