On Wed, 28 Sept 2022 at 14:54, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
On Tue, Sep 27, 2022 at 04:04:41PM +0200, Neal Gompa wrote:
> On Tue, Sep 27, 2022 at 3:20 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> >
> > On Tue, Sep 27, 2022 at 3:01 PM Stephen Smoogen <ssmoogen@xxxxxxxxxx> wrote:
> > >
> > >
> > >
> > > On Mon, 26 Sept 2022 at 17:56, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
> > >>
> > >> Here's my thoughts on rhel9 upgrades.
> > >>
> > >> We have 188 RHEL7 or RHEL8 instances (counting both vm's and bare hardware).
> > >>
> > >>
> > >> Some will just not move anytime soon:
> > >>
> > >
> > > Is it possible to look at these as 'why does this need fedmsg?' 'what happens if it doesn't have fedmsg', and 'do we need it?'
Sure, we can.
But at this point I think we have already gotten rid of most of the
things we really don't need. So, someone will need to make a compelling
argument for dropping things (at least to me).
> > > mailman01 is one where maybe not having it on fedmsg wouldn't be earth shattering
> > > but it also has the bigger problem of all its libraries being FTBFS in Fedora and
> > > being retired from there. At which point we go with 'do we need to run mailing lists?'
Well, until we figure out how to otherwise handle the use cases that
mailing lists handle now?
For example: all the -sig groups in pagure have mailing lists that get
all the bugs send to it. We would need to find another way to get bug
content to those groups (and still keep it private).
scm-commits is still important IMHO, because its a external record of
changes. If someone messed with git history, that might be the only
record of real changes.
devel/test/a few other lists are still active. They would have to move
to discourse or otherwise have something.
So, needs a concrete plan. I am not at all in favor of 'turn it off'
without moving all the needs.
I am not in favour of it myself. I am however aware that it is a constant push from some corners.
My main concerns are that our mailman3 is in bad shape, and I don't know if it is the correct tool for the jobs needed for some lists. I agree scm-commits needs to exist but it may make more sense as just a list of people in ldap who get emails and a mailbox which can be downloaded.
Moving mailman to a newer version is going to be a major challenge for multiple reasons:
* Major schema changes
* Customizations we did for Fedora services
* A move from Phoenix to IAD2 where I didn't calculate disk space correctly and some files were corrupted with no backups. I fixed as many as I could, but I am not sure I got all of them.
* Other one-offs where our version of things do not match any versions of what mailman3 docs say but probably due to prerelease code.
* Various tables will need to be cleaned so that we don't accidently unsubscribe everyone due to 'unimplemented' bounce features which store that a person should be someday unsubscribed or other actions.. when that code was finally implemented in a later version.
* Other tables which contain large amounts of garbage data about spam emails which never need to be seen or subscriptions which never need to be fulfilled. However there is no easy way of cleaning them, and they seem to cause all kinds of other slowdown when emails go to affected lists.
* Various slowdowns and non-responsive come when emails get sent to scm-commits and I am not sure why. It had neither a long list of subscribers or held messages. However the mailman rest api will go unresponsive when a lot of commits get to it.
Some of those have me very worried and looking for options to cut down work needed to make an update possible. However many of my options may not be useful and it is not my job to implement so I need to chill.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-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/infrastructure@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
