On Wed, May 3, 2023 at 6:38 PM Kamil Paral <[email protected]> wrote:
> On Tue, May 2, 2023 at 4:48 AM Sumantro Mukherjee <[email protected]> > 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? > Adam & Kamil, since my criteria starts with"for each release-blocking artifact", do you folks think its a good idea to site the criterion? or at least have it? I am not able to find it as well. > > >> 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 -- [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://pagure.io/fedora-infrastructure/new_issue > -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>
_______________________________________________ test 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://pagure.io/fedora-infrastructure/new_issue
