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é > > <[email protected]> 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 > > > > <[email protected]> wrote: > > > > > > > > > > (Cross-posting from the Fedrao Discusson forum: > > > > > https://discussion.fedoraproject.org/t/primary-vs-alternative-architectures-clarity-on-requirements/182392 > > > > > ; > > > > > 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, -- _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README
signature.asc
Description: This is a digitally signed message part
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
