(Cross-posting from the Fedrao Discusson forum: https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-...; feel free to respond there or here.)
This is a follow-up from yesterday's FESCo meeting (look for "primary arches" in the meeting log[1]. The current documentation[2] for what makes an architecture "primary" vs. "alternative" (or "secondary") seems to be outdated and needs some rework.
Two tiers of architectures --------------------------
Let's see what we have *today*. Quoting from the structure[3] section of the architectures wiki:
"There are two tiers of architectures with Fedora support:
"Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
"Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures."
The main takeway from the above is that for "primary" architectures, the build failures block main deliverables, while alternative arches don't.
* * *
Elsewhere on Fedora Matrix, @kevin explained that there was a time where an architecture was "primary" for *some* deliverables and "secondary" for others, which muddies the waters further.
The aim of this thread is to dispel this confusion and bring some clarity based on current practices. Once the dust settles, update the architectures[2]
Regards, Kashyap
[1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-03-0... [2] https://fedoraproject.org/wiki/Architectures [3] https://fedoraproject.org/wiki/Architectures#Structure
On Wed, Mar 4, 2026 at 2:41 AM Kashyap Chamarthy kchamart@redhat.com wrote:
(Cross-posting from the Fedrao Discusson forum: https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-...; feel free to respond there or here.)
This is a follow-up from yesterday's FESCo meeting (look for "primary arches" in the meeting log[1]. The current documentation[2] for what makes an architecture "primary" vs. "alternative" (or "secondary") seems to be outdated and needs some rework.
Two tiers of architectures
Let's see what we have *today*. Quoting from the structure[3] section of the architectures wiki:
"There are two tiers of architectures with Fedora support: "Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd). "Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures."The main takeway from the above is that for "primary" architectures, the build failures block main deliverables, while alternative arches don't.
* * *Elsewhere on Fedora Matrix, @kevin explained that there was a time where an architecture was "primary" for *some* deliverables and "secondary" for others, which muddies the waters further.
The aim of this thread is to dispel this confusion and bring some clarity based on current practices. Once the dust settles, update the architectures[2]
Today, I would say the only meaningful separation of architecture levels is at the Koji level. If there is a separate Koji instance, it is secondary and non-blocking. Every architecture today in primary Koji cannot actually fail, and therefore effectively operates as primary architectures.
That is the reality and that's what the document should say.
(And yes, this means I am also against importing RISC-V into the main Koji for the time being. I do not know if I would be okay with bringing it into main Koji for several years, as past investment performance with other architectures is not a good inspiration of confidence for this.)
-- 真実はいつも一つ！/ Always, there's only one truth!
On Wed, Mar 04, 2026 at 03:58:29AM -0800, Neal Gompa wrote:
On Wed, Mar 4, 2026 at 2:41 AM Kashyap Chamarthy kchamart@redhat.com wrote:
(Cross-posting from the Fedrao Discusson forum: https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-...; feel free to respond there or here.)
This is a follow-up from yesterday's FESCo meeting (look for "primary arches" in the meeting log[1]. The current documentation[2] for what makes an architecture "primary" vs. "alternative" (or "secondary") seems to be outdated and needs some rework.
Two tiers of architectures
Let's see what we have *today*. Quoting from the structure[3] section of the architectures wiki:
"There are two tiers of architectures with Fedora support: "Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd). "Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures."The main takeway from the above is that for "primary" architectures, the build failures block main deliverables, while alternative arches don't.
* * *Elsewhere on Fedora Matrix, @kevin explained that there was a time where an architecture was "primary" for *some* deliverables and "secondary" for others, which muddies the waters further.
The aim of this thread is to dispel this confusion and bring some clarity based on current practices. Once the dust settles, update the architectures[2]
Today, I would say the only meaningful separation of architecture levels is at the Koji level. If there is a separate Koji instance, it is secondary and non-blocking. Every architecture today in primary Koji cannot actually fail, and therefore effectively operates as primary architectures.
That is the reality and that's what the document should say.
Who is the target of this explanation / document ?
Talking about koji instances implicitly means the target is Fedora maintainers.
If we're instead trying to inform end users, then a different focus for the explanation would be better, as they don't care for details about how the distro is made, just the characteristics of what is delivered to them.
An end user would see a primary architecture as something that is delivered at time of co-ordinated Fedora release with the full feature set available, and fully supported with bug & security fixes for the full documented lifetime of the distro.
A secondary arch meanwhile may or may not be delivered on the co-ordinated Fedora release day, it could (in theory) lag by some days. It may also only have a subset of the Fedora features available. It may have lesser support, with delayed bug fixing / security fixes, or possibly missing enti rely.
With regards, Daniel
On Wed, Mar 4, 2026 at 4:15 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Mar 04, 2026 at 03:58:29AM -0800, Neal Gompa wrote:
On Wed, Mar 4, 2026 at 2:41 AM Kashyap Chamarthy kchamart@redhat.com wrote:
(Cross-posting from the Fedrao Discusson forum: https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-...; feel free to respond there or here.)
This is a follow-up from yesterday's FESCo meeting (look for "primary arches" in the meeting log[1]. The current documentation[2] for what makes an architecture "primary" vs. "alternative" (or "secondary") seems to be outdated and needs some rework.
Two tiers of architectures
Let's see what we have *today*. Quoting from the structure[3] section of the architectures wiki:
"There are two tiers of architectures with Fedora support: "Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd). "Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures."The main takeway from the above is that for "primary" architectures, the build failures block main deliverables, while alternative arches don't.
* * *Elsewhere on Fedora Matrix, @kevin explained that there was a time where an architecture was "primary" for *some* deliverables and "secondary" for others, which muddies the waters further.
The aim of this thread is to dispel this confusion and bring some clarity based on current practices. Once the dust settles, update the architectures[2]
Today, I would say the only meaningful separation of architecture levels is at the Koji level. If there is a separate Koji instance, it is secondary and non-blocking. Every architecture today in primary Koji cannot actually fail, and therefore effectively operates as primary architectures.
That is the reality and that's what the document should say.
Who is the target of this explanation / document ?
Talking about koji instances implicitly means the target is Fedora maintainers.
If we're instead trying to inform end users, then a different focus for the explanation would be better, as they don't care for details about how the distro is made, just the characteristics of what is delivered to them.
The Koji instances are the primary point inferring everything else, though.
An end user would see a primary architecture as something that is delivered at time of co-ordinated Fedora release with the full feature set available, and fully supported with bug & security fixes for the full documented lifetime of the distro.
A secondary arch meanwhile may or may not be delivered on the co-ordinated Fedora release day, it could (in theory) lag by some days. It may also only have a subset of the Fedora features available. It may have lesser support, with delayed bug fixing / security fixes, or possibly missing enti rely.
This pretty much can't happen if it's on the primary Koji instance. Only secondary Koji instances would be able to lag.
On Wed, Mar 04, 2026 at 04:18:22AM -0800, Neal Gompa wrote:
On Wed, Mar 4, 2026 at 4:15 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Mar 04, 2026 at 03:58:29AM -0800, Neal Gompa wrote:
On Wed, Mar 4, 2026 at 2:41 AM Kashyap Chamarthy kchamart@redhat.com wrote:
(Cross-posting from the Fedrao Discusson forum: https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-...; feel free to respond there or here.)
This is a follow-up from yesterday's FESCo meeting (look for "primary arches" in the meeting log[1]. The current documentation[2] for what makes an architecture "primary" vs. "alternative" (or "secondary") seems to be outdated and needs some rework.
Two tiers of architectures
Let's see what we have *today*. Quoting from the structure[3] section of the architectures wiki:
"There are two tiers of architectures with Fedora support: "Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd). "Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures."The main takeway from the above is that for "primary" architectures, the build failures block main deliverables, while alternative arches don't.
* * *Elsewhere on Fedora Matrix, @kevin explained that there was a time where an architecture was "primary" for *some* deliverables and "secondary" for others, which muddies the waters further.
The aim of this thread is to dispel this confusion and bring some clarity based on current practices. Once the dust settles, update the architectures[2]
Today, I would say the only meaningful separation of architecture levels is at the Koji level. If there is a separate Koji instance, it is secondary and non-blocking. Every architecture today in primary Koji cannot actually fail, and therefore effectively operates as primary architectures.
That is the reality and that's what the document should say.
Who is the target of this explanation / document ?
Talking about koji instances implicitly means the target is Fedora maintainers.
If we're instead trying to inform end users, then a different focus for the explanation would be better, as they don't care for details about how the distro is made, just the characteristics of what is delivered to them.
The Koji instances are the primary point inferring everything else, though.
Of course, but that's not helpful to end users, as they mostly don't have the knowledge to make such inferrences.
Hence wondering whether the goal of this thread is to present a explanation of primary vs secondary arches that is meaningful to end users, or an explanation that is only meaningful to packagers, or to try to target both.
An end user would see a primary architecture as something that is delivered at time of co-ordinated Fedora release with the full feature set available, and fully supported with bug & security fixes for the full documented lifetime of the distro.
A secondary arch meanwhile may or may not be delivered on the co-ordinated Fedora release day, it could (in theory) lag by some days. It may also only have a subset of the Fedora features available. It may have lesser support, with delayed bug fixing / security fixes, or possibly missing enti rely.
This pretty much can't happen if it's on the primary Koji instance. Only secondary Koji instances would be able to lag.
True, but there's more to delivery than just building the packages.
Even if the individual packages are required to pass build due to being handled by primary koji, a secondary arch could still be a lesser offering, given things that happen post Koji, such as composes and testing. A secondary arch might not be a release blocker, so we might decide to ship known broken stuff for a secondary arch. Or say shipping a subset of deliverables if certain compose tasks failed in a secondary arch only, eg shipping with installer ISOs, but not VM images due to a failure in image building.
With regards, Daniel
On Wed, 2026-03-04 at 12:31 +0000, Daniel P. Berrangé wrote:
On Wed, Mar 04, 2026 at 04:18:22AM -0800, Neal Gompa wrote:
On Wed, Mar 4, 2026 at 4:15 AM Daniel P. Berrangé berrange@redhat.com wrote:
On Wed, Mar 04, 2026 at 03:58:29AM -0800, Neal Gompa wrote:
On Wed, Mar 4, 2026 at 2:41 AM Kashyap Chamarthy kchamart@redhat.com wrote:
(Cross-posting from the Fedrao Discusson forum: https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-... ; feel free to respond there or here.)
This is a follow-up from yesterday's FESCo meeting (look for "primary arches" in the meeting log[1]. The current documentation[2] for what makes an architecture "primary" vs. "alternative" (or "secondary") seems to be outdated and needs some rework.
Two tiers of architectures
Let's see what we have *today*. Quoting from the structure[3] section of the architectures wiki:
"There are two tiers of architectures with Fedora support:
"Primary Architectures : These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
"Alternative Architectures : These are architectures with motivated Architecture Maintainer Teams. There are two classes of Alternative Architecturs, the ones built in Primary koji where build failures are fatal and ones built on their own koji instances where build failures on the alternative architecture are not fatal: if packages successfully build for the primary koji, they push independently of any alternative architecture build successes or failures."
The main takeway from the above is that for "primary" architectures, the build failures block main deliverables, while alternative arches don't.
* * *
Elsewhere on Fedora Matrix, @kevin explained that there was a time where an architecture was "primary" for *some* deliverables and "secondary" for others, which muddies the waters further.
The aim of this thread is to dispel this confusion and bring some clarity based on current practices. Once the dust settles, update the architectures[2]
Today, I would say the only meaningful separation of architecture levels is at the Koji level. If there is a separate Koji instance, it is secondary and non-blocking. Every architecture today in primary Koji cannot actually fail, and therefore effectively operates as primary architectures.
That is the reality and that's what the document should say.
Who is the target of this explanation / document ?
Talking about koji instances implicitly means the target is Fedora maintainers.
If we're instead trying to inform end users, then a different focus for the explanation would be better, as they don't care for details about how the distro is made, just the characteristics of what is delivered to them.
The Koji instances are the primary point inferring everything else, though.
Of course, but that's not helpful to end users, as they mostly don't have the knowledge to make such inferrences.
Hence wondering whether the goal of this thread is to present a explanation of primary vs secondary arches that is meaningful to end users, or an explanation that is only meaningful to packagers, or to try to target both.
An end user would see a primary architecture as something that is delivered at time of co-ordinated Fedora release with the full feature set available, and fully supported with bug & security fixes for the full documented lifetime of the distro.
A secondary arch meanwhile may or may not be delivered on the co-ordinated Fedora release day, it could (in theory) lag by some days. It may also only have a subset of the Fedora features available. It may have lesser support, with delayed bug fixing / security fixes, or possibly missing enti rely.
This pretty much can't happen if it's on the primary Koji instance. Only secondary Koji instances would be able to lag.
True, but there's more to delivery than just building the packages.
Even if the individual packages are required to pass build due to being handled by primary koji, a secondary arch could still be a lesser offering, given things that happen post Koji, such as composes and testing. A secondary arch might not be a release blocker, so we might decide to ship known broken stuff for a secondary arch. Or say shipping a subset of deliverables if certain compose tasks failed in a secondary arch only, eg shipping with installer ISOs, but not VM images due to a failure in image building.
Indeed - one concrete example here is the discussion not too long ago about whether Fedora KDE aarch64 should be considered release blocking or not. It is now, but even before that, all the packages are built because it's on the primary Koji, just that critical bugs affecting only that edition+arch would not block the entire release.
So we probably have two different levels of being a primary architecture - at the package level and at the deliverable level, though one is a precondition for the other.
Best regards,
On Wed, Mar 04, 2026 at 01:16:19PM +0000, Michel Lind wrote:
On Wed, 2026-03-04 at 12:31 +0000, Daniel P. Berrangé wrote:
On Wed, Mar 04, 2026 at 04:18:22AM -0800, Neal Gompa wrote:
On Wed, Mar 4, 2026 at 4:15 AM Daniel P. Berrangé berrange@redhat.com wrote:
An end user would see a primary architecture as something that is delivered at time of co-ordinated Fedora release with the full feature set available, and fully supported with bug & security fixes for the full documented lifetime of the distro.
Yeah, the user-facing documentation should focus on this aspect. The details of where things are built should stay in our internal docs.
A secondary arch meanwhile may or may not be delivered on the co-ordinated Fedora release day, it could (in theory) lag by some days. It may also only have a subset of the Fedora features available. It may have lesser support, with delayed bug fixing / security fixes, or possibly missing enti rely.
This pretty much can't happen if it's on the primary Koji instance. Only secondary Koji instances would be able to lag.
True, but there's more to delivery than just building the packages.
Even if the individual packages are required to pass build due to being handled by primary koji, a secondary arch could still be a lesser offering, given things that happen post Koji, such as composes and testing. A secondary arch might not be a release blocker, so we might decide to ship known broken stuff for a secondary arch. Or say shipping a subset of deliverables if certain compose tasks failed in a secondary arch only, eg shipping with installer ISOs, but not VM images due to a failure in image building.
Indeed - one concrete example here is the discussion not too long ago about whether Fedora KDE aarch64 should be considered release blocking or not. It is now, but even before that, all the packages are built because it's on the primary Koji, just that critical bugs affecting only that edition+arch would not block the entire release.
So we probably have two different levels of being a primary architecture - at the package level and at the deliverable level, though one is a precondition for the other.
The decision about deliverables can be done at the level of single deliverable. E.g. the amd64 spin with sway may or may not be blocking, mostly independently of the status of amd64 _architecture_.
So I think we should still scrap the concept of "secondary architectures". For users, we should make them aware of the status of individual deliverables.
Zbyszek
On Wed, Mar 04, 2026 at 01:44:49PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 04, 2026 at 01:16:19PM +0000, Michel Lind wrote:
[...]
So we probably have two different levels of being a primary architecture - at the package level and at the deliverable level, though one is a precondition for the other.
The decision about deliverables can be done at the level of single deliverable. E.g. the amd64 spin with sway may or may not be blocking, mostly independently of the status of amd64 _architecture_.
So I think we should still scrap the concept of "secondary architectures". For users, we should make them aware of the status of individual deliverables.
The phrase "make them aware of the status" is doing some heavy-lifting here. How would you describe this status? I'm all for simplicity, BTW!
* * *
Since we're split between forum and the list, I'll copy/paste Fabio's response from the forum[1]; he suggests a classification on "3 axes":
(quote)
I always found this classification less than helpful and mostly confusing.
For package maintainers, there is no difference between a “Primary” architecture and an “Alternative” architecture that is also built in the “primary” koji - if a package build fails on any of the architectures in either group, the build is marked as “failed”.
So to me this has always seemed as if it is kind of mixing 1) “marketing” terms with 2) technical / implementation differences and 3) QA guarantees, and creates a confusing classification that isn’t quite correct from any of the three viewpoints. Maybe it would make sense to classify architectures on those three axes separately, not creating a pseudo-classification that doesn’t fit any of them?
(/quote)
At first I thought this is more detailed than is needed and "someone" needs to keep it all in sync. To which Fabio makes the good point (on the forum) that:
"it also doesn’t change that often. The last time architecture support changed was … dropping Big-Endian PowerPC (ppc64)? That was in Fedora 29"
[1] https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-...
Regards, Kashyap
So, this sort of appeared after a casual bit of discussion the other day. I hadn't really dug into what was desired here yet. :)
That said....
We have:
https://fedoraproject.org/wiki/Architectures
It's less out of date that I thought it was, but it is still a bit confusing. Mostly around 'alternative' arches (there's two kinds: those in the primary koji and those not.).
I'd like to overhall it and move it into docs.fedoraproject.org (I guess under fesco policy?).
I don't think primary vs alternative arches make much sense as terms, or at least as they are currently defined. I'd suggest:
primary arches - those arches that are build in the main fedora koji.
alternative arches - those arches not built in the main fedora koji
but perhaps we need more distinction on alternative, because we have things that are just stood up by some folks in the community and could be one off efforts (I recompiled a bunch of stuff on $foo arch), or a community group stands up their own koji and builds things ongoing, or (as riscv is now) a infra managed koji is setup and community folks build things in an ongoing way and work to get parity with primary.
Of course there's even more shades in there, for example, right now the risc-v koji is using community builders because we don't have any dedicated ones yet. Having those would be requirement before trying to promote it to the main koji.
Additionally, we have Architecture Maintainer Teams defined there. There are still ppc64le, s390x, aarch64 specific maintainers around who handle rare corner cases, but do we still want to have all those requirements and responsiblities for them? and/or should that only be for 'up and coming' arches? Some things make no sense anymore like regular meetings on irc. ;)
kevin
On Wed, Mar 04, 2026 at 12:12:14PM -0800, Kevin Fenzi wrote:
So, this sort of appeared after a casual bit of discussion the other day. I hadn't really dug into what was desired here yet. :)
That said....
We have:
https://fedoraproject.org/wiki/Architectures
It's less out of date that I thought it was, but it is still a bit confusing. Mostly around 'alternative' arches (there's two kinds: those in the primary koji and those not.).
I'd like to overhall it and move it into docs.fedoraproject.org (I guess under fesco policy?).
I don't think primary vs alternative arches make much sense as terms, or at least as they are currently defined. I'd suggest:
primary arches - those arches that are build in the main fedora koji.
alternative arches - those arches not built in the main fedora koji
Sounds good too me.
but perhaps we need more distinction on alternative, because we have things that are just stood up by some folks in the community and could be one off efforts (I recompiled a bunch of stuff on $foo arch), or a community group stands up their own koji and builds things ongoing, or (as riscv is now) a infra managed koji is setup and community folks build things in an ongoing way and work to get parity with primary.
If community folks do something official, we don't even need to describe this in official docs.
Of course there's even more shades in there, for example, right now the risc-v koji is using community builders because we don't have any dedicated ones yet. Having those would be requirement before trying to promote it to the main koji.
Additionally, we have Architecture Maintainer Teams defined there. There are still ppc64le, s390x, aarch64 specific maintainers around who handle rare corner cases, but do we still want to have all those requirements and responsiblities for them? and/or should that only be for 'up and coming' arches? Some things make no sense anymore like regular meetings on irc. ;)
I'd drop anything that is not currently done, i.e. most of the second part of that wiki page.
Zbyszek
On Wed, Mar 04, 2026 at 09:07:39PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 04, 2026 at 12:12:14PM -0800, Kevin Fenzi wrote:
[...]
I'd like to overhall it and move it into docs.fedoraproject.org (I guess under fesco policy?).
Sounds fine to me.
I don't think primary vs alternative arches make much sense as terms, or at least as they are currently defined. I'd suggest:
primary arches - those arches that are build in the main fedora koji.
alternative arches - those arches not built in the main fedora koji
Sounds good too me.
Yeah, sounds clear enough to me.
but perhaps we need more distinction on alternative, because we have things that are just stood up by some folks in the community and could be one off efforts (I recompiled a bunch of stuff on $foo arch), or a community group stands up their own koji and builds things ongoing, or (as riscv is now) a infra managed koji is setup and community folks build things in an ongoing way and work to get parity with primary.
If community folks do something official, we don't even need to describe this in official docs.
Your sentence is tripping me up. Just to make sure I parsed you right: did you mean:
"if community folks do something official, it doesn't needs describing in the docs" (because "official stuff", by definition, is allowed; and should already be described in some form)
Or did you mean this?
"if community folks do something *non-official*, we don't even need to describe this in official docs"
At any rate, I get your main point :)
Of course there's even more shades in there, for example, right now the risc-v koji is using community builders because we don't have any dedicated ones yet. Having those would be requirement before trying to promote it to the main koji.
Yeah, the Fedora RISC-V community does consider it a requirement (having the hardware in the Fedora datacenter); it's being tracked here:
https://forge.fedoraproject.org/riscv/planning/issues/6 [Tracker] RISC-V builders in Fedora datacenter #6
Additionally, we have Architecture Maintainer Teams defined there. There are still ppc64le, s390x, aarch64 specific maintainers around who handle rare corner cases, but do we still want to have all those requirements and responsiblities for them? and/or should that only be for 'up and coming' arches? Some things make no sense anymore like regular meetings on irc. ;)
I'd drop anything that is not currently done, i.e. most of the second part of that wiki page.
The "Logistics" and "Packaging Issues" sections in the second part are still largely accurate and apply here:
https://fedoraproject.org/wiki/Architectures#Logistics https://fedoraproject.org/wiki/Architectures#Packaging_Issues
From a quick read, these need fixing:
- The URLs in the "File Storage" section needs to be updated
- In the "ExcludeArch & ExclusiveArch" section, it says:
"There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling"
I don't think this is happening.
Regards, Kashyap
On Thu, 5 Mar 2026 15:23:04 +0100 Kashyap Chamarthy kchamart@redhat.com wrote:
On Wed, Mar 04, 2026 at 09:07:39PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 04, 2026 at 12:12:14PM -0800, Kevin Fenzi wrote:
[...]
I'd like to overhall it and move it into docs.fedoraproject.org (I guess under fesco policy?).
Sounds fine to me.
I don't think primary vs alternative arches make much sense as terms, or at least as they are currently defined. I'd suggest:
primary arches - those arches that are build in the main fedora koji.
alternative arches - those arches not built in the main fedora koji
Sounds good too me.
Yeah, sounds clear enough to me.
but perhaps we need more distinction on alternative, because we have things that are just stood up by some folks in the community and could be one off efforts (I recompiled a bunch of stuff on $foo arch), or a community group stands up their own koji and builds things ongoing, or (as riscv is now) a infra managed koji is setup and community folks build things in an ongoing way and work to get parity with primary.
If community folks do something official, we don't even need to describe this in official docs.
Your sentence is tripping me up. Just to make sure I parsed you right: did you mean:
"if community folks do something official, it doesn't needs describing in the docs" (because "official stuff", by definition, is allowed; and should already be described in some form)Or did you mean this?
"if community folks do something *non-official*, we don't even need to describe this in official docs"At any rate, I get your main point :)
Of course there's even more shades in there, for example, right now the risc-v koji is using community builders because we don't have any dedicated ones yet. Having those would be requirement before trying to promote it to the main koji.
Yeah, the Fedora RISC-V community does consider it a requirement (having the hardware in the Fedora datacenter); it's being tracked here:
https://forge.fedoraproject.org/riscv/planning/issues/6 [Tracker] RISC-V builders in Fedora datacenter #6Additionally, we have Architecture Maintainer Teams defined there. There are still ppc64le, s390x, aarch64 specific maintainers around who handle rare corner cases, but do we still want to have all those requirements and responsiblities for them? and/or should that only be for 'up and coming' arches? Some things make no sense anymore like regular meetings on irc. ;)
I'd drop anything that is not currently done, i.e. most of the second part of that wiki page.
The "Logistics" and "Packaging Issues" sections in the second part are still largely accurate and apply here:
https://fedoraproject.org/wiki/Architectures#Logistics https://fedoraproject.org/wiki/Architectures#Packaging_IssuesFrom a quick read, these need fixing:
The URLs in the "File Storage" section needs to be updated
In the "ExcludeArch & ExclusiveArch" section, it says:
"There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling"
I don't think this is happening.
you mean for RISC-V work or generally? Because we have the per-arch trackers in bugzilla and the the arch-excludes mailing list for detected changes in spec files and the summaries.
Dan
On Thu, Mar 05, 2026 at 04:09:16PM +0100, Dan Horák wrote:
you mean for RISC-V work or generally? Because we have the per-arch trackers in bugzilla and the the arch-excludes mailing list for detected changes in spec files and the summaries.
To clarify, we have:
excludearch for s390x: https://bugzilla.redhat.com/show_bug.cgi?id=485231 excludearch for arm: https://bugzilla.redhat.com/show_bug.cgi?id=485251 excludearch for ppc: https://bugzilla.redhat.com/show_bug.cgi?id=238953
and
https://lists.fedoraproject.org/archives/list/arch-excludes@lists.fedoraproj...
which gets any commits that exclude arches in it along with reports about that.
I don't know if it's too early to make a riscv one or not.
kevin
On Thu, Mar 05, 2026 at 11:38:27AM -0800, Kevin Fenzi wrote:
[...]
To clarify, we have:
excludearch for s390x: https://bugzilla.redhat.com/show_bug.cgi?id=485231 excludearch for arm: https://bugzilla.redhat.com/show_bug.cgi?id=485251 excludearch for ppc: https://bugzilla.redhat.com/show_bug.cgi?id=238953
and
https://lists.fedoraproject.org/archives/list/arch-excludes@lists.fedoraproj...
which gets any commits that exclude arches in it along with reports about that.
Yep, noted.
I don't know if it's too early to make a riscv one or not.
Maybe it's not yet required for now; as we're doing most of the tracking work in the newly created Forge tracker[1].
To wrap up this discussion here, you wanted to move this doc under docs.fedoraproject.org — if you haven't already started on it, I can take a stab at it based on the info from this thread. I'll ping you on Matrix to sync.
[1] https://forge.fedoraproject.org/riscv/planning/issues/
Regards, Kashyap
On Mon, Mar 09, 2026 at 11:34:54AM +0100, Kashyap Chamarthy wrote:
On Thu, Mar 05, 2026 at 11:38:27AM -0800, Kevin Fenzi wrote:
[...]
To clarify, we have:
excludearch for s390x: https://bugzilla.redhat.com/show_bug.cgi?id=485231 excludearch for arm: https://bugzilla.redhat.com/show_bug.cgi?id=485251 excludearch for ppc: https://bugzilla.redhat.com/show_bug.cgi?id=238953
and
https://lists.fedoraproject.org/archives/list/arch-excludes@lists.fedoraproj...
which gets any commits that exclude arches in it along with reports about that.
Yep, noted.
I don't know if it's too early to make a riscv one or not.
Maybe it's not yet required for now; as we're doing most of the tracking work in the newly created Forge tracker[1].
To wrap up this discussion here, you wanted to move this doc under docs.fedoraproject.org — if you haven't already started on it, I can take a stab at it based on the info from this thread. I'll ping you on Matrix to sync.
Sure! If you would like to come up with a initial draft, happy to provide feedback.
kevin
On Thu, Mar 05, 2026 at 04:09:16PM +0100, Dan Horák wrote:
On Thu, 5 Mar 2026 15:23:04 +0100
[...]
The "Logistics" and "Packaging Issues" sections in the second part are still largely accurate and apply here:
https://fedoraproject.org/wiki/Architectures#Logistics https://fedoraproject.org/wiki/Architectures#Packaging_IssuesFrom a quick read, these need fixing:
The URLs in the "File Storage" section needs to be updated
In the "ExcludeArch & ExclusiveArch" section, it says:
"There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling"
I don't think this is happening.
you mean for RISC-V work or generally?
I assumed in general without checking closely (I did take a look now - see further below).
For RISC-V we're tracking it here (despite the issue's title, it deals with both 'ExcludeArch' and "ExclusiveArch):
https://forge.fedoraproject.org/riscv/planning/issues/3 Audit packages omitting riscv64 from 'ExclusiveArch'
Because we have the per-arch trackers in bugzilla and the the arch-excludes mailing list for detected changes in spec files and the summaries.
I see, I didn't know about the 'arch-excludes' list[1]. Thanks for the correction.
I also took a look at this page[2], and from a random click on s390x tracker, I see there are still issues[3] being added to the "F-ExcludeArch-s390x" tracker. And I see the "F-ExcludeArch-ARM" tracker is moved to 'ARMTracker'.
The "ExcludeArch Tracker for i386" also seems somewhat active, as a bug says in a comment from Sep 2025, that "it is no longer required required to file tracking issues for packages that "ExcludeArch: i686" since Fedora 37". So that link must be removed from the "Architecture Build Failures" section here[2].
[1] https://lists.fedoraproject.org/archives/list/arch-excludes@lists.fedoraproj... [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_bui... [3] https://bugzilla.redhat.com/show_bug.cgi?id=2415478
Regards, Kashyap
On Thu, Mar 05, 2026 at 03:23:04PM +0100, Kashyap Chamarthy wrote:
On Wed, Mar 04, 2026 at 09:07:39PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 04, 2026 at 12:12:14PM -0800, Kevin Fenzi wrote:
[...]
I'd like to overhall it and move it into docs.fedoraproject.org (I guess under fesco policy?).
Sounds fine to me.
I don't think primary vs alternative arches make much sense as terms, or at least as they are currently defined. I'd suggest:
primary arches - those arches that are build in the main fedora koji.
alternative arches - those arches not built in the main fedora koji
Sounds good too me.
Yeah, sounds clear enough to me.
but perhaps we need more distinction on alternative, because we have things that are just stood up by some folks in the community and could be one off efforts (I recompiled a bunch of stuff on $foo arch), or a community group stands up their own koji and builds things ongoing, or (as riscv is now) a infra managed koji is setup and community folks build things in an ongoing way and work to get parity with primary.
If community folks do something official, we don't even need to describe this in official docs.
Your sentence is tripping me up. Just to make sure I parsed you right: did you mean:
"if community folks do something *non-official*, we don't even need to describe this in official docs"
I meant this ^. Sorry for the wordo.
I'd drop anything that is not currently done, i.e. most of the second part of that wiki page.
The "Logistics" and "Packaging Issues" sections in the second part are still largely accurate and apply here:
https://fedoraproject.org/wiki/Architectures#Logistics https://fedoraproject.org/wiki/Architectures#Packaging_Issues
Ack.
From a quick read, these need fixing:
The URLs in the "File Storage" section needs to be updated
In the "ExcludeArch & ExclusiveArch" section, it says:
"There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling"
I don't think this is happening.
That sound like something that wouldn't scale very well, so I don't think we'd want to re-introduce anything like that.
The wiki maintains history, so we should just drop stuff like that.
Zbyszek
On Fri, Mar 06, 2026 at 09:37:36AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
From a quick read, these need fixing:
The URLs in the "File Storage" section needs to be updated
In the "ExcludeArch & ExclusiveArch" section, it says:
"There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling"
I don't think this is happening.
That sound like something that wouldn't scale very well, so I don't think we'd want to re-introduce anything like that.
The wiki maintains history, so we should just drop stuff like that.
So, now I feel like an idiot ignoramus, after reading the rest of the thread. Let's take the opportunity to add the links to the mailing lists there so that people can actually sign up for this if they need to.
Zbyszek
On Fri, Mar 06, 2026 at 09:37:36AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Mar 05, 2026 at 03:23:04PM +0100, Kashyap Chamarthy wrote:
On Wed, Mar 04, 2026 at 09:07:39PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 04, 2026 at 12:12:14PM -0800, Kevin Fenzi wrote:
From a quick read, these need fixing:
The URLs in the "File Storage" section needs to be updated
In the "ExcludeArch & ExclusiveArch" section, it says:
"There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling"
I don't think this is happening.
That sound like something that wouldn't scale very well, so I don't think we'd want to re-introduce anything like that.
I remember working on a git hook that was doing this back end. It's likely it has been dropped since, but a toddler could be built to do that *if* we still see value in having this. That being said, if it has been dropped for a while, there are high chances we no longer see value/the need for it :)
Pierre
On Fri, Mar 06, 2026 at 11:22:11AM +0100, Pierre-Yves Chibon wrote:
On Fri, Mar 06, 2026 at 09:37:36AM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Mar 05, 2026 at 03:23:04PM +0100, Kashyap Chamarthy wrote:
On Wed, Mar 04, 2026 at 09:07:39PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 04, 2026 at 12:12:14PM -0800, Kevin Fenzi wrote:
From a quick read, these need fixing:
The URLs in the "File Storage" section needs to be updated
In the "ExcludeArch & ExclusiveArch" section, it says:
"There is a process running that will notify architecture maintainers of all changes in Exclude and Exclusive Arch headers along with daily summaries of all packages with architecture specific handling"
I don't think this is happening.
That sound like something that wouldn't scale very well, so I don't think we'd want to re-introduce anything like that.
I remember working on a git hook that was doing this back end. It's likely it has been dropped since, but a toddler could be built to do that *if* we still see value in having this.
I'm confused. The hook is still there and working that I can see?
It does seem to have a fair bit of false positives (it emails when any arch conditional changes, so things like kernel/gcc where patches or the like change it emails), but it seems like it's working to me?
That being said, if it has been dropped for a while, there are high chances we no longer see value/the need for it :)
Well, as far as I can tell it's working... but of course that doesn't say if it's of use or not. :)
kevin
On Wed, Mar 04, 2026 at 12:15:06PM +0000, Daniel P. Berrangé wrote:
On Wed, Mar 04, 2026 at 03:58:29AM -0800, Neal Gompa wrote:
[...]
Today, I would say the only meaningful separation of architecture levels is at the Koji level. If there is a separate Koji instance, it is secondary and non-blocking. Every architecture today in primary Koji cannot actually fail, and therefore effectively operates as primary architectures.
That is the reality and that's what the document should say.
Who is the target of this explanation / document ?
Talking about koji instances implicitly means the target is Fedora maintainers.
Right, I should've made the audience clearer. As you guessed, the target audience is indeed Fedora pacakge maintainers and "motivated Architecture Maintainer Teams" as the doc calls it. Not traditional end-users of Fedora.
If we're instead trying to inform end users, then a different focus for the explanation would be better, as they don't care for details about how the distro is made, just the characteristics of what is delivered to them.
Yeah, to step back a bit, this topic came up on the Fedora RISC-V Matrix channel, and Kevin Fenzi responded with some historical detail for aarch64. While it was fresh in his mind, he ended up discussing it in the FESCo meeting that happened right after that.
The larger context of this discussion is we (Fedora RISC-V SIG) are figuring out a "path to primary arch" document for RISC-V. Many things have to fall in place, including hardware vendors sticking to the announced timlines, Koji builder hardware in the Fedora datacenter (right now all Koji builder hardware is community-donated). We're writing a document; we'll post it here once we have a draft.
[...]
A secondary arch meanwhile may or may not be delivered on the co-ordinated Fedora release day, it could (in theory) lag by some days. It may also only have a subset of the Fedora features available. It may have lesser support, with delayed bug fixing / security fixes, or possibly missing enti rely.
Yeah, that's how it is today for Fedora RISC-V. It's a small team. This has been the status I began working on this since last March:
- F42: for the first time, the F42 RISC-V images went out the same day as primary architectures
- F43: a high-severity 'debuginfo' bug derailed many packages; ~92% of F43 for RISC-V was ready for a while but the rest was hit by this bug;it took time to sort it out working with relevant maintainers, and rebuild all the affected pacakges
- F44: it's very unlikely to go out along with the primary release, for various reasons; F44 mass-rebuild for RISC-V is yet to start (https://forge.fedoraproject.org/riscv/planning/issues/11)
[...]
Regards, Kashyap
-
Dan Horák -
Daniel P. Berrangé -
Kashyap Chamarthy -
Kevin Fenzi -
Michel Lind -
Neal Gompa -
Pierre-Yves Chibon -
Zbigniew Jędrzejewski-Szmek