Toolbox aka Toolbx should be usable.

Toolbox should be able to list, create and provide the desired containerized environment to the user without root privileges.

Toolbox images should be generally functional.

Footnote - "What does this cover?": Toolbox's general functionality as covered by this test cases https://fedoraproject.org/wiki/QA:Testcase_toolbox

I think this criterion could target F39 Beta Release Criteria or Basic Release Criteria [2].

There is a push from the Dekstop team to have toolbox as a default app in the installer iso as well.

~~~~~~~~~~~~ Toolbox aka Toolbx should be usable. Toolbox should be able to list, create and provide the desired containerized environment to the user without root privileges. Toolbox images should be generally functional. Footnote - "What does this cover?": Toolbox's general functionality as covered by this test cases https://fedoraproject.org/wiki/QA:Testcase_toolbox ~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For any release-blocking deliverable whose default deployment includes toolbox, it must be possible to list existing containers, enter them, and create a new one. Footnote - "What does this cover?": Toolbox CLI should offer commands to be executed by the user which includes listing existing container images created by the toolbox, creating container images with the latest Fedora and RHEL and entering these containers. This criterion aims at blocking only the toolbox rpm functionality and not the OCI image which is supposed to be downloaded by user's choice. https://fedoraproject.org/wiki/QA:Testcase_toolbox ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hello This has been silent for a long time now but here's the update. Debarshi and I decided to re-write the whole thing as a changeset[0]. We DO care about not just the rpm but also the OCI image that we ship with Toolbx. As a result, we filed a releng ticket[1] where we justified the following: We need the image ready for branch point, beta and final and that image be blocked implying we resort to "no-go" if the expected image is not there at all. As the basic functionality of toolbx continues to work as intended, we would also like to block on any upcoming changeset, if that has the potential to break toolbx or toolbx OCI image deliverables as well. Read [2] for more exact things that might break toolbx. Finally, GNOME WS, Silverblue, FCOS include Toolbx as part of their deliverable. RHEL does the same. It's crucial that we block on this. However, as the changeset process rolls, we will go through FESCO as well. This is just a good time for us to ensure we all are on the same page and have the plumbing done beforehand!

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, create a new container with the latest Fedora and RHEL image, and enter it. OCI images should get updates in every stage of the release cycle (Branched, Beta and Final). Footnote - "What does this cover?": This criterion aims at blocking Toolbx OCI image and Toolbx rpms. 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. The images must be present in registry.fedoraproject.org and must keep being updated like for branchpoints, beta and final. Missing images or broken images, will be blocking the release. Changes in Toolbx stack will warrant for a test day in that particular release cycle and regular validation to ensure there are no regressions.

On Tue, May 2, 2023 at 9:04 AM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > > On Mon, May 1, 2023 at 10:48 PM Sumantro Mukherjee <sumukher(a)redhat.com&gt; wrote: > > > > Hello > > > > > > This has been silent for a long time now but here's the update. > > Debarshi and I decided to re-write the whole thing as a changeset[0]. > > We DO care about not just the rpm but also the OCI image that we ship > > with Toolbx. As a result, we filed a releng ticket[1] where > > we justified the following: We need the image ready for branch point, > > beta and final and that image be blocked implying we resort to "no-go" > > if the expected image is not there at all. > > > > As the basic functionality of toolbx continues to work as intended, we > > would also like to block on any upcoming changeset, if that > > has the potential to break toolbx or toolbx OCI image deliverables as > > well. Read [2] for more exact things that might break toolbx. > > > > Finally, GNOME WS, Silverblue, FCOS include Toolbx as part of their > > deliverable. RHEL does the same. It's crucial that we block > > on this. However, as the changeset process rolls, we will go through > > FESCO as well. This is just a good time for us to ensure > > we all are on the same page and have the plumbing done beforehand! > > > > I'd also like to preload toolbx on Fedora KDE: > https://pagure.io/fedora-kde/SIG/issue/346 > > We already ship it for Fedora Kinoite. yaaaayyyy!!!!

On Tue, May 2, 2023 at 4:48 AM Sumantro Mukherjee <sumukher(a)redhat.com&gt; wrote: > Debarshi and I decided to re-write the whole thing as a changeset[0]. > Great, I think this is the best approach. > The revised criterion I have now stands as: > Does it make sense to wait for the FESCo approval before we finalize the exact criterion wording? I don't want to spend too much time on it in advance, when we're not sure about the outcome :-)

_______________________________________________ test mailing list -- test(a)lists.fedoraproject.org To unsubscribe send an email to test-leave(a)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

FESCo has approved[0] this changeset and now the criterion needs to be in place. I will gather all the knowledge and the corrections that have been talked about in this thread and start a fresh one for voting? [0] https://pagure.io/fesco/issue/3002

The new proposed criteria taking Kamil's and Adam's suggestions goes as follows : Once people are okay with it, I can go ahead and add this to the criterion? ~~~~~~~~~~~~~~~~~~~~~ For any release-blocking deliverable whose default deployment includes Toolbx, the <code>toolbox</code> CLI must be able to list existing containers, create a new container with the latest Fedora and RHEL image, and enter it. Footnote - "What does this cover?": The images must be present in registry.fedoraproject.org ~~~~~~~~~~~~~~~~~~~~~~~~~

On Tue, Jun 20, 2023 at 12:07 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote: > ~~~~~~~~~~~~~~~~~~~~~ > For any release-blocking deliverable whose default deployment includes > Toolbx, the {{command|toolbox}} CLI must be able to list existing > containers. One nitpick, it's not clear whether "list" means listing local containers or remote containers (all in the registry). So perhaps say "list existing local containers", or something similar?

Thanks a lot Kamil and Adamw!! Can I go and publish this under the Beta criteria? :) @Kamil Paral <kparal(a)redhat.com&gt; it will be awesome, if you can point me to the correct criteria template , please?

On Tue, May 02, 2023 at 08:18:07AM +0530, Sumantro Mukherjee wrote: > Hello > > > This has been silent for a long time now but here's the update. > Debarshi and I decided to re-write the whole thing as a changeset[0]. > We DO care about not just the rpm but also the OCI image that we ship > with Toolbx. As a result, we filed a releng ticket[1] where > we justified the following: We need the image ready for branch point, > beta and final and that image be blocked implying we resort to "no-go" > if the expected image is not there at all. If we start building the oci image as part of composes, it will be not failable, that is, if it doesn't compose, the compose fails and nothing is produced. :) Of course, it might compose and still have some kind of breakage and will need testing for that. Note that as far as I know there's not any critera/testing for branch point. We just get a successfull compose there. Beta and Final are actually releases with testing, etc.

On Tue, May 2, 2023 at 4:48 AM Sumantro Mukherjee <sumukher(a)redhat.com&gt; 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(a)lists.fedoraproject.org To unsubscribe send an email to test-leave(a)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

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