On 2/28/25 11:47 AM, Clement Verna wrote: > > On Fri, 28 Feb 2025 at 17:35, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx <mailto:adamwill@xxxxxxxxxxxxxxxxx>> wrote: > > On Fri, 2025-02-28 at 08:56 -0500, Dusty Mabe wrote: > > Last Wednesday there was a grub2-2.12-24.fc43 update [1] that came in that completely broke booting > > in CoreOS. For whatever reason this same update didn't break testing in OpenQA of other editions, > > but we knew immediately [2] that it broke us and reported negative karma on the update [3]. Despite > > this we were powerless to prevent the update from flowing in without somehow making contact with > > the maintainers. > > Well, not exactly. I believe I mentioned this to you in chat: you can > request that the update be untagged. Before openQA was gating for > Rawhide, we actually did this quite a lot (so much that I was thinking > of it as 'soft gating' for a while). > > File a ticket at https://pagure.io/releng/issues <https://pagure.io/releng/issues> and request that the > build be untagged . Like e.g. https://pagure.io/releng/issue/12464 <https://pagure.io/releng/issue/12464> . > Someone from releng will probably look at it very quickly (if not, you > can ping on the Matrix channel). > > We used to be very, very gunshy about untagging things, but with > various changes to the Rawhide workflow in recent years we just aren't > any more. Especially if the build has not yet made it to a compose, > untagging is entirely possible. If you get the build untagged before > the next compose happens, it will never appear in the 'real' public > Rawhide repo. > > > If you do get a build untagged, I usually find it's a good idea to add > a comment to the Bodhi update for the build explaining why, and just > generally make sure the issue is followed up on and resolved, not just > left to fester till the next build happens for unrelated reasons. > > > Doing this for a while is actually a great way to build up a concrete > justification for turning on 'real' gating (I referenced the history of > builds being untagged in response to openQA testing when we turned on > Rawhide gating). > > > Oh, thanks for highlighting this. Indeed I think that can be a good first step towards enabling full gating. > > @Dusty Mabe <mailto:dusty@xxxxxxxxxxxxx> , how about doing this for the F43 development cycle? This give us a good way to "protect" to CoreOS builds as well as getting more data for turning on "real" gating as adamw mentioned. > When F43 branches from Rawhide we can then open a FESCO ticket to discuss enabling gating. Indeed. I think it's a good first step. The only thing I don't like is having to track somebody down to do the untagging. Maybe under a special request a few of us could be given the powers to untag? My proposal here would be that the process is still open a ticket (tracking purposes), but then be able to act on it too. If it turns out the untagging was unwarranted after further investigation I'd also like to be able to "undo" my gating mistake and then record that in the ticket. I guess I can propose this to FESCO as Zbyszek mentioned. Sound good? Dusty -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
