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é > > > <[email protected]> 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 -- _______________________________________________ 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
