Re: Proposal: gate all stable release updates on rmdepcheck

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

-- 
_______________________________________________
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

-----BEGIN PGP SIGNATURE-----

iJAEABYKADgWIQRdzi5+nDsc/9M1wdeLIp0vfMwE8gUCalEqFRocc2FsaW1tYUBm
ZWRvcmFwcm9qZWN0Lm9yZwAKCRCLIp0vfMwE8gzeAQCDWyCt32I24PvI9BnsSRMM
9TrBmfNTboJj0uNjH2HN2AD/bTirxWH/KxlagbSglhcDmVU5HpdIcnXiucwlq3r5
kA0=
=Y4JD
-----END PGP SIGNATURE-----