On Tue, 2026-07-07 at 18:28 +0100, Adam Williamson wrote: > On Tue, 2026-07-07 at 18:27 +0100, Adam Williamson wrote: > > On Tue, 2026-07-07 at 09:56 -0700, Kevin Fenzi wrote: > > > > > > > > And while I kind of agree that the Change process does not seem > > > > to be > > > > *great* fit for this, but similar changes *have* gone through > > > > the > > > > Change process before (like > > > > https://fedoraproject.org/wiki/Changes/GatingRawhidePackages ). > > > > Should > > > > a system-wide change (lower case intentional) like this require > > > > at > > > > least *some* kind of signoff from FESCo? > > > > > > I suppose it might be a good idea to get a fesco ack here. > > > But also, I think this should be flexable so if it's enabled and > > > some > > > big problem appears it can be disabled again until thats > > > addressed, etc. > > > > Also, that Change isn't really similar to the current case at all. > > That > > Change was really about building the *mechanism* to allow per- > > package > > opt-in gating, and it actually also encompassed the on-demand side > > tag > > creation work too. So it was a lot of detailed engineering work > > across > > multiple key components (Bodhi, greenwave, fedpkg etc.) > > > > This is...not that. This is adding a couple of lines to > > https://forge.fedoraproject.org/infra/ansible/src/branch/main/roles/openshift-apps/greenwave/templates/fedora.yaml.j2 > > and running the playbook, which I can do in five minutes. And if it > > all > > goes pear-shaped, we revert the commit and run the playbook again. > > > > I'll note we did not go through the Change process when enabling > > gating > > on openQA tests, either - neither when we initially did it for > > stable > > releases, nor when we extended it to Rawhide and Branched. I did > > the > > same thing as this, more or less - floated it on the mailing lists > > and > > in some chats, waited for feedback, then went ahead and did it. > > That's > > been working out fine. > > Whoops, forgot to say: I'd be fine with filing a FESCo ticket asking > for approval, though.
I'm fine with a lightweight vote (and would vote in favour). As careful as one can be when submitting updates, mistakes happen (recently I had two updates that were in flight simultaneously, and one ended up having a dependency issue caused by the other landing first, but both were fine at the time of submission). One tweak to this - can we force a re-run before promoting a package from testing->stable as well, because as the example above showed (this is the rpki 0.19.3-1 update vs the quick-xml 0.41 update, FWIW) - testing once might not be enough as the state might have changed in subsequent composes? Best regards, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
signature.asc
Description: This is a digitally signed message part
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
