Seems fine to me in principle. In practice, I agree we need it to be generated as part of the compose process (or, if not literally as part of a Pungi compose run, at least done by releng in some sort of automated way that publishes messages) in order to make this feasible.

If it can be made part of the compose process, specific release criteria aren't even really necessary - we can just mark it as a critical (non-failable) deliverable, which would mean composes would fail if it did not build. It should be added to the https://docs.fedoraproject.org/en-US/releases/f37/blocking/ list (well, the f38 or later one) in that case.

Thinking it through a bit further, if we were to make it one of those things - which the criteria refer to as 'release-blocking images' - it would automatically be subject to a large chunk of the release criteria; we could tweak the release criteria text a little to make sure it all made sense as applied to a container image, as we have recently done for CoreOS and IoT.

I agree, if this image is considered blocking by the Workstation WG, it should be in the release blocking list linked above. I guess that would involve a discussion with Fedora program management, because they maintain the page. We'll then make sure that our criteria apply well, with that container image included.

I think that eventually we need to expand the scope to have working Toolbx, beyond having an updated fedora-toolbox image, as a release blocking criterion because it touches too many different parts of the operating system. eg., changes to Fedora's Kerberos stack can cause Kerberos to stop working inside Toolbx containers, changes to the sysctl(8) configuration can break ping(8), changes in Mutter can break graphical applications, etc.. It's a growing list that's not easy to keep up with without some extra diligence. :)

I left a longer comment about this on the fedora-workstation ticket.

so, current status is that we have criteria: https://fedoraproject.org/wiki/Fedora_40_Beta_Release_Criteria#Toolbx_functionality , we have a wiki testcase: https://fedoraproject.org/wiki/QA:Testcase_toolbox , and we have openQA testing . A bit of a loophole is that none of the testing really ensures that we test exactly the toolbox image built as part of the compose; I think usually we will in fact be testing whatever image was last pushed 'stable', such that a standard toolbox enter command deploys it. But on the whole I think this is pretty well covered. I can try and figure out how to write a test that actually uses the toolbox image from the compose under test though too, I guess.

follow-up issue: https://pagure.io/fedora-qa/issue/766