I'm looking at this change: https://pagure.io/fedora-qa/relval/c/04a9b9e0227c14dc8627fa3a85ea177707ab9cf5?branch=size-check-bz
And if I read it correctly, the bug is only created once per release, and it's only set to blocking when a release-blocking image is oversize at that very time. Which means, correct me if I'm wrong, that we're very likely to miss size-check errors again, when it goes like this: 1. During a release, the first time an image goes over size, it's a non-release-blocking image 2. relval files a bug but doesn't make it block Beta or Final 3. In the next compose, a release-blocking image goes over size 4. relval updates the bug comment, but doesn't block Beta or Final, so the bug doesn't pop up in blocker bug app 5. Somebody notices two days before Go/No-Go 6. People are upset
Unless I miss something, this is a very likely scenario (I'd even say 90+% likely, because spins are usually oversize and release blocking images are usually not). So we really need relval to set blocks: Beta Final each time a release-blocking image is detected to be over size. Of course there are some annoyances resulting from that approach. In order to make it better, I imagine we could have two different bugs reported, one for non-release-blocking and one for release-blocking. That could make the following human process fairly reasonable. Or, to make it completely simple, just don't check image size for anything that is not release-blocking. Spins are completely self-reliant and we don't necessarily need to file these bugs for them.
blocks: Beta Final
I'm reading the code again and I guess I misunderstood the code. You create a separate bug for each available image, correct? So Workstation Live x86_64 gets a separate bug from an XFCE Live x86_64 and from XFCE Live arm64, right? If that's the case, we can disregard this whole ticket, I was wrong when filing it.
A thing to remember, though, is that we should never touch blocks: F30Beta F30Final e.g. by manually removing F30Final during pre-beta stage, because the code never touches the blocks: field again, and therefore we could then miss oversize issues against Final later on. So we should not touch that. Or, alternatively, the code could always ensure both the targets are present in the blocks: field. That would be a more defensive approach (I usually prefer that). Having both targets present all the time doesn't negatively affect us in any way (neither during pre-beta nor during pre-final).
blocks: F30Beta F30Final
F30Final
blocks:
Also, since this is an automatic blocker, why is not AcceptedBlocker automatically filled in?
AcceptedBlocker
Yeah, I really wasn't sure what was the optimal strategy for poking the trackers. I went with something conservative just in case things work out weird in real life (as they have a tendency to). But we can tweak it, especially since @kevin pointed me at that file in infra ansible that can be used to check what phase we're in. I'll have a look at it soon.
One thing I'm not 100% sure of is what blockerbugs does if a bug is marked as blocking both Beta and Final. I'm not sure if it will always show up under one of the two, randomly show up under one of the two, or always show up under both.
But we can tweak it, especially since @kevin pointed me at that file in infra ansible that can be used to check what phase we're in. I'll have a look at it soon.
I recommend to always file against both Beta and Final, even with Kevin's suggestion, because it avoids any timing issues and doesn't have any negative impact. (Well, a real negative impact. It'd somewhat skew our bookkeeping numbers, which might trigger some of our OCDs:)).
I tested it and it shows up correctly under both milestones. :thumbsup:
Login to comment on this ticket.