Re: new criterion proposal: toolbox functionality

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

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

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:
List Guidelines:
List Archives:
Do not reply to spam, report it:

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux