Re: new criterion proposal: toolbox functionality

[Neal Gompa]

On Tue, May 2, 2023 at 12:00 AM Sumantro Mukherjee  wrote:
>
>
>
> On Tue, May 2, 2023 at 9:04 AM Neal Gompa  wrote:
>>
>> On Mon, May 1, 2023 at 10:48 PM 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.
>> >
>> > 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.
>
>
> y


Note that my desire to preload it depends on a guarantee
that it isn't broken and works on GA.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: new criterion proposal: toolbox functionality

[Sumantro Mukherjee]

On Tue, May 2, 2023 at 9:04 AM Neal Gompa  wrote:

> On Mon, May 1, 2023 at 10:48 PM 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.
> >
> > 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.
>

y

>
> > 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.
> >
>
> "will warrant for a" -> "will warrant a"
>
> otherwise lgtm.
>
>
Thanks for the review!


-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED 
___
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

Re: new criterion proposal: toolbox functionality

[Neal Gompa]

On Mon, May 1, 2023 at 10:48 PM 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.
>
> 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.

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

"will warrant for a" -> "will warrant a"

otherwise lgtm.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: new criterion proposal: toolbox functionality

[Sumantro Mukherjee]

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.







[0] https://fedoraproject.org/w/index.php?title=Changes/ToolbxReleaseBlocker
[1] https://pagure.io/releng/issue/11399
[2] 
https://fedoraproject.org/w/index.php?title=Changes/ToolbxReleaseBlocker#Detailed_Description




-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
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

2023-05-01 - Fedora QA Meeting - Minutes

[Adam Williamson]

==
#fedora-meeting: Fedora QA meeting
==


Meeting started by adamw at 15:00:37 UTC. The full logs are available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-05-01/fedora-qa.2023-05-01-15.00.log.html
.



Meeting summary
---
* Roll Call  (adamw, 15:00:47)

* Previous meeting follow-up  (adamw, 15:06:05)
  * no action items at last meeting  (adamw, 15:06:51)
  * ACTION: adamw to migrate release criteria from the wiki to docs.fp.o
(bcotton, 15:11:23)

* Fedora 38 and 39 check-in  (adamw, 15:18:13)
  * Fedora 38 seems to be going over generally well, there's a potential
issue with upgrades crashing, see
https://bugzilla.redhat.com/show_bug.cgi?id=2187837 and preserve all
logs if you encounter this  (adamw, 15:35:03)
  * Fedora 39 (Rawhide) is fairly stable at present  (adamw, 15:35:14)

* Test Day / community event status  (adamw, 15:35:28)
  * the call for Test Days has gone out, please go ahead and file a
ticket if you'd like to propose a Test Day for Fedora 39 cycle:

https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org/message/BVGUCIDZ7RJ7RR5PZMCCC5RYB5D4ACMQ/
(adamw, 15:36:16)

* Open floor  (adamw, 15:41:59)

Meeting ended at 15:47:27 UTC.




Action Items

* adamw to migrate release criteria from the wiki to docs.fp.o




Action Items, by person
---
* adamw
  * adamw to migrate release criteria from the wiki to docs.fp.o
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* adamw (55)
* bcotton (15)
* zodbot (9)
* tflink[m] (6)
* coremodule_ (3)
* nirik (1)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions

-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
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

2023-05-01 @ 15:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2023-05-01
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.libera.chat

Greetings testers!

It's meeting time again! Sorry for the late notice on this; I was away
for the weekend without any device that's set up to send Fedora
emails...

If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.

== Proposed Agenda Topics ==

1. Previous meeting follow-up
2. Fedora 38 and 39 check-in
3. Test Day / community event status
4. Open floor
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



___
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