# F43 Blocker Review meeting
# Date: 2025-09-29
# Time: 16:00 UTC
# Location:
https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.…
Hi folks! It's time for a Fedora 43 blocker review meeting! We have 2
proposed blockers and 2 proposed freeze exceptions for Final.
Here is a handy link which should show you the meeting time
in your local time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+41+Blocker…
The meeting will be on Matrix. Click the link above to join in a web
client - you can authenticate with your FAS account - or use a
dedicated client of your choosing.
If you have time today, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F43 can be found on the
wiki [0].
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
Have a good day and see you tomorrow!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net
As agreed upon yesterday on out meeting, let’s discuss how to migrate our pagure repo to forgejo.
Based on my current knowledge, I would suggest initially aiming for the following structure:
repo: wg-conducts
The subject matter is the ongoing completion of our tasks and projects. Data includes, in particular, tracking issues and long-term (sub)project planning and discussion.
repo: usrdoc
The subject matter is the maintenance of our user documentation articles and, in particular, factual issues and PRs (https://docs.fedoraproject.org/en-US/fedora-server/) We should separate this from our WG documentation, which we currently maintain in a shared repository. The workflows are very different.
repo: wgdoc
The subject here is the text of our WG documentation (https://docs.fedoraproject.org/en-US/server-working-group/) We should not maintain this together with our user documentation in one repository.
It may be useful to merge these into the wg-conducts repo.
repo: ansiblesupport
The subject here is our Ansible scripts for supporting the administrative installation and maintenance of various Fedora Server Services.
I think that's what we need first and foremost. And for each repo, we then have to look for ways to meet our requirements, e.g., notifications for new issues or commits, formatting a preview for documentation pages, etc.
If we start our Homelab Server Appliance project we may create another repo for that.
The migration tool does not offer any way to modify the repository to be migrated. This must be done either before or after using standard Git procedures.
Let's discuss the plannings so that we can decide on the best course of action at next week's meeting and then get started right away (and let’s get the naming and wording right).
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast
# F43 Blocker Review meeting
# Date: 2025-09-22
# Time: 16:00 UTC
# Location:
https://matrix.to/#/#blocker-review:fedoraproject.org?web-instance[element.…
Hi folks! It's time for a Fedora 43 blocker review meeting! We have 10
proposed blockers and 2 proposed freeze exceptions for Final.
Here is a handy link which should show you the meeting time
in your local time:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=Fedora+41+Blocker…
The meeting will be on Matrix. Click the link above to join in a web
client - you can authenticate with your FAS account - or use a
dedicated client of your choosing.
If you have time today, you can take a look at the proposed or
accepted blockers before the meeting - the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .
Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F43 can be found on the
wiki [0].
For more information about the Blocker and Freeze exception process,
check out these links:
- https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
- https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
- https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
Have a good day and see you tomorrow!
[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net
Even with the latest branched compose we still have the bug in arm-image-installer. The proposal to treat this as a release blocker was rejected. However, it is a freeze exception, so a fix can still be added very late in the release process. The status of the bug (https://bugzilla.redhat.com/show_bug.cgi?id=2391231) is still “new”. It looks as if no one has taken care of it yet.
Another problem is that the image produced, is very likely not bootable at all, even if the bug in arm-image-installer gets fixed. In any case, neither the minimal image nor the workstation and XFCe images that do not use LVM and work for arm-image-installer, do boot with the current release 43 build. This has been verified for the Radxa Pi 4 and the Pine64 RockPro64 and presumably affects all RockChip models. However, these are precisely the models that are particularly suitable for Server. And so far, we have no evidence that any SBC other than the Raspberry Pi 4 can be installed.
The release is scheduled for October 28, and the freeze date is October 7. That leaves about four weeks to fix the problem. In about two weeks, we should decide how to proceed in a worst-case scenario. One possible alternative would be to simply do nothing and let things run their course, i.e., intentionally release a non-functional release. The alternative would be to drop the image and possibly publish a note on our documentation on the download page with information on how Fedora Server can still be used on an SBC (fallback to F41 and step-by-step DNF upgrade). Otherwise, this could be included in the release notes and common bugs.
This is now the second time that we are about to publish a non-functional server release. We should consider in the long term whether we want to put ourselves through this mess on a more or less regular basis. Unlike IoT and CoreOS, which have their own separate release process and can make their own decisions, we are integrated into the general Fedora process and are only a small part amongst a large number of different desktops. We can only gain reliability and predictability if the Server SBC release becomes a blocker criterion again. As Adam discovered, this was the case for up to a 2x release for the 32-bit Arm image and was not carried over to the transition to 64-bit.
I suggest we look into this option. If that's not acceptable, we should still publish the SBC image for current users with the next release (F44), but at the same time declare it deprecated and drop it completely with the release after that. Fedora could continue to produce the image and publish it on the alternative/experimental versions page, but no longer under Server Downloads.
We could continue to leave the section about SBCs in our documentation for users/interested parties and otherwise focus on SBCs that have SR-compatible firmware and can be installed with the standard aarch64 ISO. This works very well with the Radxa Rock 5, for example, where the manufacturer also supports the EDK2 firmware. A variety of other models from the newer board generation are also supported, but I have not yet been able to test them. In terms of performance, we would then be in a range where the boards can compete with Intel or AMD mini servers (e.g., based on N100) and have some advantages over them. So these are seriously useable devices.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast