On Tue, 10 Jan 2023 at 17:37, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote:
Hi,
... clipped as I want to focus on this part.
(4) As another reply mentioned, to get LoongArch as a primary Fedora
architecture, an essential requirement is 19" rackable server-class
hardware. It needs to be fully manageable through a BMC. Fedora will
probably need a few such servers to be donated.
This is usually the major hanging point for bringing up it as a 'main' OS. I am going to outline in depth what it takes from an operational side to get any new 'deliverable' into Fedora currently. I am not doing so to say 'this can't be done' as much as to explain why it can't usually be done at the speed most people seem to think can be done.
The complete Fedora koji build system has a lot of assumptions of being in the same datacenter with just one set of hardware remote and 'breaking' regularly due to that (mounts are being done over NFS over ssh and disconnect regularly.. connections between the main DC and other places may time out etc.). The build system is generally locked together so that if one architecture has slowness/problems it affects all builds on the other arches. Adding more architectures to this tends to add a non-linear complexity in places. [The opposite of having multiple koji's adds a different level of complexity and requires more dedicated people time which is in even shorter supply.]
The complete Fedora koji build system has a lot of assumptions of being in the same datacenter with just one set of hardware remote and 'breaking' regularly due to that (mounts are being done over NFS over ssh and disconnect regularly.. connections between the main DC and other places may time out etc.). The build system is generally locked together so that if one architecture has slowness/problems it affects all builds on the other arches. Adding more architectures to this tends to add a non-linear complexity in places. [The opposite of having multiple koji's adds a different level of complexity and requires more dedicated people time which is in even shorter supply.]
The main DC is in the continental United States and in a 'lights' out facility (aka there are no hands in the facility regularly). This means that the hardware needs to be able to be managed remotely and be redundant so that it can 'work' in a degraded shape for weeks until replacements can be reached. There is no 'lab' for fixing equipment so the parts generally need to have a dedicated tech to fix. [Practically this means the hardware in the facility needs to be rated and insurable for this sort of data-center. Certain hardware is rated only for 'labs' or places where someone can unplug quickly if it smokes.. this is not that kind of place.]
The next issue is space to put more equipment into this facility. Pretty much every build architecture takes at least 1 full sized rack for the number of systems needed to keep up with builds. That requires additional planning as the space used is shared between multiple groups and may not be possible to add in quickly (or at all). Other solutions are possible but would require additional work and time. There are also the requirements for additional NFS storage, power, etc etc that each deliverable requires. Those all need to be added, budgeted for and purchased. [What has happened several times to slow things down is that it wasn't ordered/budgeted/purchased/put-in-place.. and well 6-12 months got lost making it happen.]
That all sounds like a lot of 'no' wrapped up in a 'it depends', but it can be done. In general it can be a 2-5 year process from when someone says 'Hey wouldn't it be great to build X' to getting the 'factory' built and working with the rest of the build system. During that time, usually a secondary external build system may be built elsewhere using shadow-koji or some other build tools to keep up and work out a lot of the bugs in the many parts of the build system (bodhi, koji, pungi, odcs, osbs, git, bugzilla, messaging system, pdc, mbs, oci, signing-infra, qa, koschei, and various things which are containers that affected/are affected by any build). Doing that allows for the eventual infusion of the arch into the main Fedora to take weeks versus months/year.
This is the main reason why RISC-V isn't a primary Fedora architecture
yet, although progress is happening.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
