We're playing constant cat-and-mouse game with the image max size limits, and we know that most of the limits are fake and can be raised any time. Those are not release blockers, it's just a convenient way for us to deal with image size increases. I believe we should separate those two use cases, and I've written some ideas here. But because of upcoming Pagure migration, I'll repost it here as well:

My view is that we're misusing release criteria for getting hard-to-miss notifications and playing with optimizations. That's not what release criteria are supposed to be about. There should be an actual reason for why the max size limit is what it is. I.e. targeting the intended DVD/thumbdrive/SDcard size, or perhaps in the case of a netinst, the max size of what we want to fit as a whole into memory, when booted over PXE, reflecting our documented minimal hw requirements. Having the Damocles' sword dangling above the whole Fedora release, just because an image is a few MB larger than an arbitrary optimization limit, if we know the limit is fake and can be raised any time (and so we raise it and keep ourselves whole 30MB headroom, so that we can repeat it next cycle), is not a great process in my eyes. We keep doing this every single release.

I won't try to convince people to change the process so late in the release, but I wanted to express my thoughts here, and hopefully people can think about it and we can discuss a different way of handling this for the next release. I have a few ideas [1] [2], and others might have betters ones, which we can discuss post-F43.

[1] Separate a hard limit and a notification limit. Let QA enforce the hard limit, and send notifications (to be determined where) for the notification limit, so that image owners and interested parties can look at trimming the size whenever it grows larger than they wanted it.
[2] Look at relative numbers instead of absolute, so if the new image is e.g. 20% or 30% larger than the same image in the previous release, block the release unless the image owner waives the change. This guards us from sudden unexpected size spikes, while avoiding the "must trim a few MBs or else" minigames. This can still be combined with actual hard limits, for the DVD/thumbdrive/SDcard/etc scenarios.

Let's work on finding a better solution, if there's agreement among people.