On Thu, 5 Mar 2026 15:23:04 +0100 Kashyap Chamarthy <[email protected]> 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 #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
