On Fri, 21 Apr 2023 at 17:20, Florian Weimer <fweimer@xxxxxxxxxx> wrote:
> For lists that are active, the split is confusing — when should
> something be on the packaging list rather than devel? What happens when
> something is related to both Cloud and Server, or Workstation and KDE?
> One can post to both lists, but if someone replies and isn’t subscribed
> to both, the conversation gets split.
Do Fedora mailing lists reject mail from non-members, and redirect
follow-ups?
Yes we have to. Most of the email coming to any of the fedora mailing lists is spam email from non-subscribers. A good portion of it is 'smart' SPAM where it replies to a specific email with headers to make it pop into an existing thread. Fiddling with various spam controls to better handle that has continually caused important developers emails to start being marked as SPAM.
The first thing we did was to have non-member email moderated for the lists. This sounds great but the amount of queued email on many lists is in the order of 100k or more emails. The problem is that the version of mailman3 uses some sort of linked list to keep track of all those queued emails. Every email seems to get checked against that queue which then slows down the overall system. Last year we were getting hour long timeouts on mailman3, and I then spent about 3 man-weeks of volunteer time to go through only about 100 mailing lists to clean out the 100k queues on each of them. I stopped when the timeouts got down to a 'normal' amount but the amount of junk email on the many email lists is a lot. There are probably ways to do this directly in the postgres database, but my attempts required restores from backups due to 'differences between our beta setup and what is expected'.
Trying to upgrade mailman3 to a version which may be better has been,I think, a 5 year task of continual frustration. When I was in infrastructure, everyone always had about 10 other tasks of higher priority that HAD to be done to keep other parts of Fedora running. When I left infrastructure, that increased the tasks for the remaining people to 20. Hiring in a replacement just found more things which needed to be kept running so we have looked for volunteers for a while. Several attempts have been made by volunteers, but real life and the overall complexity of modern email kills it every time.
Running mailman3 is a nearly full time job to keep it working versus the lackadaisical mailman2 it replaced. Because it is trying to be both a webforum to catch that 'I don't want to use email' audience, a better archiver, and various other tooling, Things like system accounts, authentication, postgres databases, etc They are all needed to make it work.
Outside of that DNS has many new fields which need to be implemented or added to deal with slightly conflicting standards which cause various sites to not accept email if they aren't implemented in their version. New fields are added and changed regularly which require dealing with people complaining that their email is now marked as SPAM, they aren't getting the email anymore, or that we have lost email because the queues on our systems overflowed due to various people subscribing to the SCM mailing list but having a quota too small.
In any case, the issue is that there have not been for about 8 years to run this well. The task gets harder and harder over time due to complex DNS needs for email to work these days to just general time needed to clean up existing spam, deal with ham being marked as spam, etc. And when it comes down to 'does Infrastructure have time to keep builds, composes, and the 100 services running that are needed to do that' or 'does Infrastructure work on some part of an undocumented email system'.. the answer is always going to be get the daily builds out as developers complain a lot more about that than email.
It is time to explore other options. One of them is the proposal that Matthew and I guess the Council have come up with. It is using a resource which is paid for, has an open source background, and is willing to make some changes to better accommodate other workflows. If people want something else they are going to need to come up with a proposal which does not include using existing burned out resources to accomplish it.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
