Re: new criterion proposal: toolbox functionality

[Sumantro Mukherjee <sumukher@xxxxxxxxxx>]

On Wed, May 3, 2023 at 6:38 PM Kamil Paral <kparal@xxxxxxxxxx> wrote:

On Tue, May 2, 2023 at 4:48 AM Sumantro Mukherjee <sumukher@xxxxxxxxxx> 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 -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

--

//sumantro

Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED

_______________________________________________
test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue