The way we implement "test gating status" in Bodhi is a bit broken.
Each update is treated as having a singular gating status. But there are two possible gating points for an update: push to testing, and push to stable. Really, an update should have two gating statuses - gating status for push to testing, and gating status for push to stable.
This usually doesn't cause too many problems because the distro-wide policies are the same for stable and testing. But it can have odd effects for updates with per-package gating policies that don't apply the same rules to both gating points. e.g. libabigail. As you can see, its policy applies some rules for push to stable, but none for push to testing.
When you initially create a libabigail update and it's submitted to testing, it looks like we calculate the gating status for push to testing and declare that as The Update's Singular Gating Status. So at that point, the update's gating status is 'passed'. But once it reaches testing, it seems like we recalculate its gating status for push to stable, and it suddenly flips to 'failed'. You can see this in the initial cluster of state changes on https://bodhi.fedoraproject.org/updates/FEDORA-2024-6da0169ae7 :
This update has been submitted for testing by dodji.
This update's test gating status has been changed to 'passed'.
This update has been pushed to testing.
This update's test gating status has been changed to 'failed'.
this already feels a bit weird, but the really weird part is that we use the update's singular "gating status" as an input to decide whether you can push the update stable. So, if the update had gotten a couple of +1s before it was pushed to testing (so it cleared the karma requirement), the maintainer could have submitted it for stable, because its singular "gating status" was considered to be 'passed' at that point - even though it actually failed its gating configuration for push to stable, it only passed its gating configuration for push to testing. I'm not totally sure whether the update would have made it all the way to being pushed - it depends whether we'd wind up recalculating the gating status and getting a different answer at any point between it getting submitted to stable and actually being pushed - but I'm pretty sure at least that we would allow it to be submitted.
Fixing this is probably a bit complex and will require UI changes as well as backend stuff, but we should probably do it sometime.
The way we implement "test gating status" in Bodhi is a bit broken.
Each update is treated as having a singular gating status. But there are two possible gating points for an update: push to testing, and push to stable. Really, an update should have two gating statuses - gating status for push to testing, and gating status for push to stable.
This usually doesn't cause too many problems because the distro-wide policies are the same for stable and testing. But it can have odd effects for updates with per-package gating policies that don't apply the same rules to both gating points. e.g. libabigail. As you can see, its policy applies some rules for push to stable, but none for push to testing.
When you initially create a libabigail update and it's submitted to testing, it looks like we calculate the gating status for push to testing and declare that as The Update's Singular Gating Status. So at that point, the update's gating status is 'passed'. But once it reaches testing, it seems like we recalculate its gating status for push to stable, and it suddenly flips to 'failed'. You can see this in the initial cluster of state changes on https://bodhi.fedoraproject.org/updates/FEDORA-2024-6da0169ae7 :
this already feels a bit weird, but the really weird part is that we use the update's singular "gating status" as an input to decide whether you can push the update stable. So, if the update had gotten a couple of +1s before it was pushed to testing (so it cleared the karma requirement), the maintainer could have submitted it for stable, because its singular "gating status" was considered to be 'passed' at that point - even though it actually failed its gating configuration for push to stable, it only passed its gating configuration for push to testing. I'm not totally sure whether the update would have made it all the way to being pushed - it depends whether we'd wind up recalculating the gating status and getting a different answer at any point between it getting submitted to stable and actually being pushed - but I'm pretty sure at least that we would allow it to be submitted.
Fixing this is probably a bit complex and will require UI changes as well as backend stuff, but we should probably do it sometime.