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.