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