Tagging @pboy for Server WG and @kevin and @ngompa from FESCo for Everything, I guess (dunno who else 'owns' Everything). We need to do something about this or else F43 is blocked, the images are way over the 1G limits. I can get them under 1.2 but not under 1, I don't think.

1.2 seems ok to me I guess. It's just going to keep growing, but if we can try and catch any big jumps and fix them the limits are useful.

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 (you can post them here), 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.

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 mean, this isn't really necessary. We could have just bumped the limits months ago. I just never got around to proposing it because I knew I wanted to actually look into why the images were oversize and I never got the time. But it's already trivially possible to remove the SoD at any given time.

Exactly. That's why I'm saying that what we usually deal with regarding image sizes is not actually related to the release-blocking process. This is probably not the best place for this conversation, we can continue that in our QA ticket.

Im going to go ahead and merge this then. +1 to the discussion happening in QA ticket and maybe finding a better, longer term solution.

OK, I've rebased, please merge. I will update the relval metadata.