On Tue, May 2, 2023 at 4:48 AM Sumantro Mukherjee <sumuk...@redhat.com> wrote:
> The revised criterion I have now stands as: > > ~~~~ > For any release-blocking deliverable whose default deployment includes > toolbx, the toolbox CLI must be able to list existing containers, > toolbx -> Toolbx to denote you're talking about the project/software and we can also do toolbox CLI -> <code>toolbox</code> CLI to distinguish the command name > OCI images should get updates in every stage of the release cycle > (Branched, Beta and Final). > "get updates" is probably a bit confusing. You want to say that the Toolbx OCI image must be composed from the same software versions as other compose artifacts, right? This is actually a bit tricky, because sometimes some artifacts might have slightly different versions (IoT, respinning some Spins when they fail to compose, a hotfix in just one Spin, etc, it has happened before). Perhaps we can neglect that. But I wonder if this sentence is actually needed. Once Toolbox OCI is release-blocking, it will have to be built with every compose, just as Kevin said. So this will have to be true each time. And we have the same assumption basically for each release-blocking artifact. > > Footnote - "What does this cover?": > This criterion aims at blocking Toolbx OCI image and Toolbx rpms. I think this is already covered in the criterion above. > In > cases of a breaking changeset or regression which affects toolbx, we > will need to test well ahead of time to ensure things are fine. > This sentence doesn't fit into the release criteria. Just leave it out. > The images must be present in registry.fedoraproject.org This is fine. It adds extra detail to the main requirement specified above (it could be merged there or kept inside the footnote). > and must keep > being updated like for branchpoints, beta and final. Missing images or > broken images, will be blocking the release. > I think this is just assumed, as described above, for each release-blocking artifact. Honestly, I thought we have some criterion saying "all release-blocking artifacts must exist" or something along those lines, but I haven't found it :-) Adam, am I looking wrong? > Changes in Toolbx stack will warrant for a test day in that particular > release cycle and regular validation to ensure there are no > regressions. > This sentence doesn't fit into the release criteria. Just leave it out.
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
