Re: Primary vs. Alternative architectures: clarity on requirements
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/[email protected]/ > > > > 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
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/[email protected]/ > > 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Fri, Mar 06, 2026 at 11:22:11AM +0100, Pierre-Yves Chibon wrote: > On Fri, Mar 06, 2026 at 09:37:36AM +, 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 +, 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Fri, Mar 06, 2026 at 09:37:36AM +, 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 +, 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Fri, Mar 06, 2026 at 09:37:36AM +, 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Thu, Mar 05, 2026 at 03:23:04PM +0100, Kashyap Chamarthy wrote: > On Wed, Mar 04, 2026 at 09:07:39PM +, 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
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_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. > > 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/[email protected]/ [2] https://docs.fedoraproject.org/en-US/packaging-guidelines/#_architecture_build_failures [3] https://bugzilla.redhat.com/show_bug.cgi?id=2415478 Regards, Kashyap -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
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/[email protected]/ 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Thu, 5 Mar 2026 15:23:04 +0100 Kashyap Chamarthy wrote: > On Wed, Mar 04, 2026 at 09:07:39PM +, 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. 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, Mar 04, 2026 at 09:07:39PM +, 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, Mar 04, 2026 at 01:44:49PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Mar 04, 2026 at 01:16:19PM +, 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-clarity-on-requirements/182392/2 Regards, Kashyap -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, Mar 04, 2026 at 12:15:06PM +, 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 -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, Mar 04, 2026 at 01:16:19PM +, Michel Lind wrote: > On Wed, 2026-03-04 at 12:31 +, 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é > > > 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, 2026-03-04 at 12:31 +, 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é > > 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 > > > > 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, w
Re: Primary vs. Alternative architectures: clarity on requirements
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é 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 > > > 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 b
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, Mar 4, 2026 at 4:15 AM Daniel P. Berrangé 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 > > 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, Mar 04, 2026 at 03:58:29AM -0800, Neal Gompa wrote: > On Wed, Mar 4, 2026 at 2:41 AM Kashyap Chamarthy 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. 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 -- |: https://berrange.com ~~https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~https://fstop138.berrange.com :| -- ___ 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
Re: Primary vs. Alternative architectures: clarity on requirements
On Wed, Mar 4, 2026 at 2:41 AM Kashyap Chamarthy 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. (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! -- ___ 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
