Just to chime in:
I'm actually super impressed with how this transition was handled, how list admins were consulted and allowed to test their individual transitions. People were explicitly invited to try out test instances on MM3, and see if they could find any bugs. Follow-up has been extremely helpful in shooting down bugs that were bound to appear. Ahead of time, anticipated downsides were shared and where possible mitigated. People were invited to share concerns.
All in all this is a school example for how these transitions should happen. That doesn't mean that everything goes without a bump in the road, but the followed process is one that I could hardly make reasonable requests for improvement on. The fact that something doesn't exactly work out the way you hoped, does not mean that the process followed was flawed, and I think it's unfair to "summarize" this way.
Thanks a lot for all the work Kunal and Amir (and other people who undoubtedly worked on this behind the screens).
Lodewijk
On Sun, Jun 6, 2021 at 9:56 PM Kunal Mehta legoktm@debian.org wrote:
Hi,
On 6/6/21 1:02 PM, Leon Haanstra wrote:
Thank you for the information Platonides. So, summarizing the events so far. There was a transfer to mailman 3 without consulting any local communities.
I don't know what kind of consultation you wanted, but I think https://phabricator.wikimedia.org/T52864 tells the story pretty well. It's been just about 8 years since this was asked for and I'm not aware of a single person who didn't want to upgrade Mailman.
Arguments like "a more modern look" and "convenience" were used.
Well yes, but the main reason was actually security. https://phabricator.wikimedia.org/T118641 explains the flaws in MM2. We only discovered some major security/privacy issues in our MM2 setup because we started working on the migration.
The upgrade came and the persons responsible for the upgrade did so without fully releasing that there might be downsides or negative side effects.
Mailman3 is easily better than Mailman2 *overall*, but it's certainly not perfect. Some key features are worse, missing, or broken. We've asked people to file bugs and report issues to us when they encounter them, but it's taking a while to get through everything because the list keeps growing. We don't send email announcements every time we fixed something because that would be pretty spammy!
When people come forward with issue's regarding the upgrade not understanding what the issue is, the response is, take it up with Hotmail, the issue surely can't be the mailman upgrade. Microsoft should fix their stuff and if not, it's your problem.
It wasn't my intention to suggest that, sorry if it came across that way.
My take is that Mailman is sending emails that the user legitimately signed up for, and Hotmail is *bouncing* them back rather than marking them as junk or something else. I don't think Hotmail is doing the right thing there, but I think it's clear something changed on the Mailman3 side that triggered this change in Hotmail's treatment of our emails.
But at the same time I feel pretty limited in debugging problems with the CheckUser-l mailing list. There are no archives I can look at, I'm not a subscriber who gets copies of emails, and I don't want to add any logging to capture bounce messages in case they do have private/confidential data. The next Mailman version will send the raw bounce message to the listadmin (per https://gitlab.com/mailman/mailman/-/issues/908) which should give us some more info, but it's not super straightforward for me to patch our installation with, I'm still looking into that.
So for now the only suggestion I have is to reach out to Hotmail...or disable bounce processing.
Maybe we missed some setting in the migration? I'm not sure, more eyes are always appreciated, really. I and Amir and others who've already spent time on this are committed to getting this issue fixed, and we've already been doing so ever since we started the MM3 migration.
I enjoy working on mailing lists because I recognize how important they are to the movement, but it's pretty demotivating to just read "oh you didn't consult the communities" as a reason this shouldn't have been done when that's blatantly false. HTH, -- Kunal _______________________________________________ Listadmins mailing list -- listadmins@lists.wikimedia.org To unsubscribe send an email to listadmins-leave@lists.wikimedia.org
To request technical changes for a specific list, please instead create a task in Phabricator. See https://meta.wikimedia.org/wiki/Mailing_lists