#10920 Mailman restart
Closed: Will Not/Can Not fix 2 years ago by smooge. Opened 2 years ago by bcotton.

NOTE

If your issue is for security or deals with sensitive info please
mark it as private using the checkbox below.

Describe what you would like us to do:


Restart the mailman service to resolve "Mailman REST API not available. Please start Mailman core."

(pinged @eddiejennings via .oncall)

When do you need this to be done by? (YYYY/MM/DD)


ASAP


This is actually done automatically by the service. Basically our mailman3 is in very bad shape. It is running code which is long out of date, the basic code is FTBFS in Fedora and aiming for retirement soon, and we have lists which have a LOT of traffic but are not really interactive (the scm commit and similar lists get a LOT of send only traffic) so hyperkitty is useless for them.

Finally a lot of the lists have a ton of held spam and accounts (usually spammers) wanting subscriptions. I feel like when I clean those out of lists, the other pages are snappier and definitely db queries related to them do not time out like the ones with hundreds of thousands of spam and other things.

At this point, we are needing to get dedicated and permanent resources of some sort focused on communication software.

This fixed itself. Going to close it as cantfix

Metadata Update from @smooge:
- Issue close_status updated to: Will Not/Can Not fix
- Issue status updated to: Closed (was: Open)

2 years ago

At this point, we are needing to get dedicated and permanent resources of some sort focused on communication software.

Should I file a CPE initiative proposal for this? What should it entail?

Well what communication methods should Fedora provide for whom and how? This is what needs to be answered before CPE or any group could take it as an initiative.

The most active mailing lists on Fedora's mailman3 are mainly post only and going to mainly email addresses which routinely bounce because of lack of disk space or quota. mailman2 would have disabled these people and unsubscribed them, but I only found out last week that mailman3 'reports' it but doesn't actually do anything with it. Instead it fills yet another table with an entry which when the function was finally added recently caused ANYONE who had ever had this happen in the years before to be unsubscribed from all their lists. [Basically to do an update, we need to make sure a lot of tables are 'clear' before we do the update.]

These lists which cover scm commit messages and similar report only may work better as openmailbox entries where people who are interested map the drive via read-only imap or some similar tool.

The next set of mailing lists are fairly active but only a handful of people ever seem to post via hyperkitty. These probably should remain mailing lists because many of us wizards are old and cranky and won't move to a posting system like discourse.

Finally there is a set of mailing lists which do see hyperkitty posts but not a lot of other traffic. They might be better on discourse or some similar tool.

After that we need to go through what things do we need this system to 'report'. Currently we send stuff to fedmsg and some other tooling which seems to have been the bigger holdup to moving to a newer mailman3 over the years than anything else. Do we need the 0mq, fedmsg, and some other optional django things we did originally? This is again outside of CPE to implement because if the project says sending every email to fedoramessaging is also important.. then that needs to be worked on.

After that is done, then a CPE initiative could be filed.

Login to comment on this ticket.

Metadata