From 18d7ca98c784aa223c1b345483206c628c685812 Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 18:11:57 +0000 Subject: [PATCH 01/16] Create 0087-aarch64-tier1.md Suggested in [nixos-org-configurations#142](https://github.com/NixOS/nixos-org-configurations/pull/142). `aarch64-linux` gathers enough attention to receive a promotion to a supported architecture? Rendered: TBA --- rfcs/0087-aarch64-tier1.md | 66 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 rfcs/0087-aarch64-tier1.md diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md new file mode 100644 index 000000000..f31c91270 --- /dev/null +++ b/rfcs/0087-aarch64-tier1.md @@ -0,0 +1,66 @@ +--- +feature: aarch64-tier1 +start-date: 2021-03-09 +author: Vika Shleina +co-authors: TBD +shepherd-team: TBD +shepherd-leader: TBD +related-issues: TBD +--- + +# Summary +[summary]: #summary + +Move `aarch64-linux` from a Tier 2 platform to Tier 1, as described in [RFC 0046](/rfcs/0046-platform-support-tiers.md) + +# Motivation +[motivation]: #motivation + +`aarch64-linux` support in Nixpkgs and NixOS matures over time and becomes +more and more stable, and more devices appear having NixOS on ARM support. +Moving it to a Tier 1 platform will allow us to block release channels on +aarch64-related build failures, making it easier and safer for ARM users +to upgrade their systems, and will help in keeping software versions in +sync between several architectures due to `x86_64-linux` and `aarch64-linux` +builds sharing a channel. + +# Detailed design +[design]: #detailed-design + +`aarch64-linux` builds will be added to stable and unstable channels' `tested` +aggregate jobs on Hydra, giving them ability to block channel advances. + +# Examples and Interactions +[examples-and-interactions]: #examples-and-interactions + + + +In [nixos/release-combined.nix](https://github.com/NixOS/nixpkgs/blob/master/nixos/release-combined.nix) +`aarch64-linux` will be moved to `supportedSystems`, enabling NixOS tests +to block channel advances in case of failures. + +(maybe something more? IDK for now) + +# Drawbacks +[drawbacks]: #drawbacks + +Some build failures could unneccesarily delay channel advances, delaying critical updates. + +# Alternatives +[alternatives]: #alternatives + +Create an aarch64-focused channel that would build same things current `unstable` does, but for aarch64 only. + +# Unresolved questions +[unresolved]: #unresolved-questions + +TBA + +# Future work +[future]: #future-work + +TBA From 61c3f1a53085f4fb751aa8b1e0b8d87052fc2e58 Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 18:27:35 +0000 Subject: [PATCH 02/16] Elaborate on wording here and there --- rfcs/0087-aarch64-tier1.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index f31c91270..6973bfed2 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -24,11 +24,17 @@ to upgrade their systems, and will help in keeping software versions in sync between several architectures due to `x86_64-linux` and `aarch64-linux` builds sharing a channel. +`aarch64-linux` will benefit from increased binary cache coverage as an +additional result, saving on build times for end users. + # Detailed design [design]: #detailed-design -`aarch64-linux` builds will be added to stable and unstable channels' `tested` -aggregate jobs on Hydra, giving them ability to block channel advances. +If this RFC is accepted, `aarch64-linux` builds will be added to stable +and unstable channels' `tested` aggregate jobs on Hydra, giving them ability +to block channel advances. Hydra will start building aarch64 packages and run +aarch64-based tests as part of stable and unstable channels, including them in +the binary cache, increasing its coverage as a result. # Examples and Interactions [examples-and-interactions]: #examples-and-interactions @@ -58,7 +64,7 @@ Create an aarch64-focused channel that would build same things current `unstable # Unresolved questions [unresolved]: #unresolved-questions -TBA +Do we have enough machines to handle aarch64 builds without delaying `x86_64-linux` builds? # Future work [future]: #future-work From 8d3b512c1db6c0a60ae8506ac515a7b44b06e382 Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 18:54:54 +0000 Subject: [PATCH 03/16] Add a note about aarch64 builder availability Thanks @grahamc Co-authored-by: Graham Christensen --- rfcs/0087-aarch64-tier1.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 6973bfed2..7f6083c78 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -36,6 +36,11 @@ to block channel advances. Hydra will start building aarch64 packages and run aarch64-based tests as part of stable and unstable channels, including them in the binary cache, increasing its coverage as a result. +It is possible that the availability of aarch64 builders from Equinix Metal will at times be +reduced, causing delays in aarch64 build capacity. We will extend the +nixos-org-configurations implementation of hydra-provisioner to dynamically allocate +aarch64 builders on AWS during these capacity shortfalls. + # Examples and Interactions [examples-and-interactions]: #examples-and-interactions From 86a05dfa0b8c6102fbef1cc07d84d2e1b86a478e Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 19:01:09 +0000 Subject: [PATCH 04/16] Add a note about the increased cache coverage It's mostly perceived coverage due to channel bumps waiting for stuff as @samueldr noted --- rfcs/0087-aarch64-tier1.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 7f6083c78..e20dbd7cb 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -24,8 +24,9 @@ to upgrade their systems, and will help in keeping software versions in sync between several architectures due to `x86_64-linux` and `aarch64-linux` builds sharing a channel. -`aarch64-linux` will benefit from increased binary cache coverage as an -additional result, saving on build times for end users. +`aarch64-linux` will benefit from increased percieved binary cache coverage +as an additional result of channel bumps waiting for aarch64 builds to finish, +saving on build times for end users. # Detailed design [design]: #detailed-design From 1dfb043ecea22ecfd89c847ca33148cd3250cf5e Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 19:02:44 +0000 Subject: [PATCH 05/16] Elaborated on a drawback of the alternative solution Co-authored-by: Graham Christensen --- rfcs/0087-aarch64-tier1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index e20dbd7cb..ee479c3c4 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -65,7 +65,7 @@ Some build failures could unneccesarily delay channel advances, delaying critica # Alternatives [alternatives]: #alternatives -Create an aarch64-focused channel that would build same things current `unstable` does, but for aarch64 only. +Create an aarch64-focused channel that would build same things current `unstable` does, but for aarch64 only. This has a significant drawback: it is possible for the x86_64 channel and the aarch64 channels to never pass on the same commit, making deployment to a heterogeneous cluster of x86_64 and aarch64 machines very challenging. # Unresolved questions [unresolved]: #unresolved-questions From bad5164d830680e5885feb34c2e61702b1492f54 Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 19:03:56 +0000 Subject: [PATCH 06/16] Add @grahamc as a co-author Thank you for helping me with this RFC :sparkles: --- rfcs/0087-aarch64-tier1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index ee479c3c4..44b1f8285 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -2,7 +2,7 @@ feature: aarch64-tier1 start-date: 2021-03-09 author: Vika Shleina -co-authors: TBD +co-authors: Graham Christensen shepherd-team: TBD shepherd-leader: TBD related-issues: TBD From e79da89a47d6b624160b10c040126642ddcc2c1f Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 19:07:29 +0000 Subject: [PATCH 07/16] Notes about additional actions to be taken Co-authored-by: Graham Christensen --- rfcs/0087-aarch64-tier1.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 44b1f8285..791bd4d7b 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -55,7 +55,13 @@ In [nixos/release-combined.nix](https://github.com/NixOS/nixpkgs/blob/master/nix `aarch64-linux` will be moved to `supportedSystems`, enabling NixOS tests to block channel advances in case of failures. -(maybe something more? IDK for now) +Merging this RFC should happen simultaneously with the merging of documentation and perhaps +a NixOS module for configuring qemu-binfmt as an aarch64 builder on x86_64 machines. + +(**To clarify**: should we add additional documentation around `boot.binfmt.emulatedSystems` +to increase its visibility?) + +The list of NixOS AMIs on NixOS.org will also be extended to include aarch64 images. # Drawbacks [drawbacks]: #drawbacks From 6c46f9ed7b3b60e7eb1d1b3cd04bbac574bd5c93 Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 19:34:48 +0000 Subject: [PATCH 08/16] Decreased importance of the `qemu-binfmt` bits There are build failures sightings when using emulation, these need to be tracked down (but that's out-of-scope for this RFC). --- rfcs/0087-aarch64-tier1.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 791bd4d7b..15beadba0 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -55,11 +55,11 @@ In [nixos/release-combined.nix](https://github.com/NixOS/nixpkgs/blob/master/nix `aarch64-linux` will be moved to `supportedSystems`, enabling NixOS tests to block channel advances in case of failures. -Merging this RFC should happen simultaneously with the merging of documentation and perhaps -a NixOS module for configuring qemu-binfmt as an aarch64 builder on x86_64 machines. - -(**To clarify**: should we add additional documentation around `boot.binfmt.emulatedSystems` -to increase its visibility?) +Merging this RFC should happen simultaneously with the merging of documentation +around configuring qemu-binfmt as a fallback method for building aarch64 packages on +x86_64 machines. Additionally, a sub-project that's out-of-scope for this RFC may be +established to catch build failures (of which sightings were reported) when using +emulation. The list of NixOS AMIs on NixOS.org will also be extended to include aarch64 images. @@ -81,4 +81,6 @@ Do we have enough machines to handle aarch64 builds without delaying `x86_64-lin # Future work [future]: #future-work -TBA +Track down build failures when using `boot.binfmt.emulatedSystems` and qemu-binfmt to build +aarch64 packages on `x86_64-linux` machines (e.g. by building a minimal closure fully without +binary caches and emulation). From bc94559f0882467ad0c25f1d120799fb5993b599 Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 19:35:14 +0000 Subject: [PATCH 09/16] Update 0087-aarch64-tier1.md --- rfcs/0087-aarch64-tier1.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 15beadba0..ad7e15fda 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -28,6 +28,13 @@ builds sharing a channel. as an additional result of channel bumps waiting for aarch64 builds to finish, saving on build times for end users. +## Prior art +There were prior attempts at the same feat, but they failed due to technical +limitations of Hydra: + - NixOS/nixpkgs@74c4e30 - disabled in 2017 because of memory issues + - NixOS/nixpkgs#52534, NixOS/nixpkgs@36a0c13 - re-enabled in 2018 to pre-build important outputs + - NixOS/nixpkgs@1bfe8f1 - disabled again due to hydra-evaluator issues + # Detailed design [design]: #detailed-design From 6126ffab4c3241d1ecf7a838c9fe9bec4ba4f24c Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 19:43:04 +0000 Subject: [PATCH 10/16] Added a note about hydra-evaluator rewrite I forgot it!!! --- rfcs/0087-aarch64-tier1.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index ad7e15fda..042ec435b 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -35,6 +35,9 @@ limitations of Hydra: - NixOS/nixpkgs#52534, NixOS/nixpkgs@36a0c13 - re-enabled in 2018 to pre-build important outputs - NixOS/nixpkgs@1bfe8f1 - disabled again due to hydra-evaluator issues +Since then, hydra-evaluator has been rewritten, which probably will make +these concerns obsolete. + # Detailed design [design]: #detailed-design From d7f6389b707b9730c509619ae8a86d4855d7ad8d Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 20:05:31 +0000 Subject: [PATCH 11/16] Added an alternative suggestion A separate channel could let us gauge how much work we'll need to keep the channel green. Co-authored-by: Frederik Rietdijk --- rfcs/0087-aarch64-tier1.md | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 042ec435b..e93f1a47c 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -24,7 +24,7 @@ to upgrade their systems, and will help in keeping software versions in sync between several architectures due to `x86_64-linux` and `aarch64-linux` builds sharing a channel. -`aarch64-linux` will benefit from increased percieved binary cache coverage +`aarch64-linux` will benefit from increased perceived binary cache coverage as an additional result of channel bumps waiting for aarch64 builds to finish, saving on build times for end users. @@ -47,8 +47,8 @@ to block channel advances. Hydra will start building aarch64 packages and run aarch64-based tests as part of stable and unstable channels, including them in the binary cache, increasing its coverage as a result. -It is possible that the availability of aarch64 builders from Equinix Metal will at times be -reduced, causing delays in aarch64 build capacity. We will extend the +It is possible that the availability of aarch64 builders from Equinix Metal will +at times be reduced, causing delays in aarch64 build capacity. We will extend the nixos-org-configurations implementation of hydra-provisioner to dynamically allocate aarch64 builders on AWS during these capacity shortfalls. @@ -81,7 +81,16 @@ Some build failures could unneccesarily delay channel advances, delaying critica # Alternatives [alternatives]: #alternatives -Create an aarch64-focused channel that would build same things current `unstable` does, but for aarch64 only. This has a significant drawback: it is possible for the x86_64 channel and the aarch64 channels to never pass on the same commit, making deployment to a heterogeneous cluster of x86_64 and aarch64 machines very challenging. +## Create a separate channel +Create an aarch64-focused channel that would build same things current `unstable` does, +but for aarch64 only. This has a significant drawback: it is possible for the x86_64 +channel and the aarch64 channels to never pass on the same commit, making deployment +to a heterogeneous cluster of x86_64 and aarch64 machines very challenging. + +### Use a separate channel as a stepping stone +Elaborating on the previous alternative, create an aarch64-focused channel. Show +there are enough resources and commitment to keep it green for half a year to a year. +Carry on with the RFC topic once this is the case. # Unresolved questions [unresolved]: #unresolved-questions From 42a9774db72b389853d2aabcb8582a2eaf01c633 Mon Sep 17 00:00:00 2001 From: Vika Date: Tue, 9 Mar 2021 20:16:35 +0000 Subject: [PATCH 12/16] Clarified prior art Added a note that we didn't fully disable builds, just demoted the architecture to partial support. Co-authored-by: Samuel Dionne-Riel @samueldr --- rfcs/0087-aarch64-tier1.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index e93f1a47c..4a3f69059 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -33,7 +33,11 @@ There were prior attempts at the same feat, but they failed due to technical limitations of Hydra: - NixOS/nixpkgs@74c4e30 - disabled in 2017 because of memory issues - NixOS/nixpkgs#52534, NixOS/nixpkgs@36a0c13 - re-enabled in 2018 to pre-build important outputs - - NixOS/nixpkgs@1bfe8f1 - disabled again due to hydra-evaluator issues + - NixOS/nixpkgs@1bfe8f1 - demoted to partial support due to hydra-evaluator issues + +As a result, since NixOS/nixpkgs@1bfe8f1, in late 2018 NixOS already is +blocking channel releases on the base system closure required to produce the +installer image. Since then, hydra-evaluator has been rewritten, which probably will make these concerns obsolete. From 9840a0593e192759b2012e6116068413c5aa573f Mon Sep 17 00:00:00 2001 From: Vika Date: Wed, 10 Mar 2021 11:44:27 +0000 Subject: [PATCH 13/16] Mark capacity question as solved I think the note in Detailed design about getting AWS instances in case we need burst capacity solves the question about having enough CPU power. --- rfcs/0087-aarch64-tier1.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 4a3f69059..359cb907b 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -51,6 +51,9 @@ to block channel advances. Hydra will start building aarch64 packages and run aarch64-based tests as part of stable and unstable channels, including them in the binary cache, increasing its coverage as a result. +## Dealing with Capacity Issues +[design-capacity]: #design-capacity + It is possible that the availability of aarch64 builders from Equinix Metal will at times be reduced, causing delays in aarch64 build capacity. We will extend the nixos-org-configurations implementation of hydra-provisioner to dynamically allocate @@ -99,7 +102,7 @@ Carry on with the RFC topic once this is the case. # Unresolved questions [unresolved]: #unresolved-questions -Do we have enough machines to handle aarch64 builds without delaying `x86_64-linux` builds? +~~Do we have enough machines to handle aarch64 builds without delaying `x86_64-linux` builds?~~ (see [Dealing with Capacity Issues](#design-capacity)) # Future work [future]: #future-work From 483c402e87ecb30cd2610057bca2c7eeccd429f6 Mon Sep 17 00:00:00 2001 From: Vika Date: Wed, 10 Mar 2021 11:45:15 +0000 Subject: [PATCH 14/16] Fixed a link --- rfcs/0087-aarch64-tier1.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 359cb907b..1d6395d39 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -102,7 +102,7 @@ Carry on with the RFC topic once this is the case. # Unresolved questions [unresolved]: #unresolved-questions -~~Do we have enough machines to handle aarch64 builds without delaying `x86_64-linux` builds?~~ (see [Dealing with Capacity Issues](#design-capacity)) +~~Do we have enough machines to handle aarch64 builds without delaying `x86_64-linux` builds?~~ (see [Dealing with Capacity Issues](#dealing-with-capacity-issues)) # Future work [future]: #future-work From 1f67d1fc27fc77b12a6c172673f5258ad96f7070 Mon Sep 17 00:00:00 2001 From: Vika Date: Mon, 16 Aug 2021 20:21:22 +0300 Subject: [PATCH 15/16] Update 0087-aarch64-tier1.md Added the shepherd team --- rfcs/0087-aarch64-tier1.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index 1d6395d39..d6a939cfc 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -3,8 +3,8 @@ feature: aarch64-tier1 start-date: 2021-03-09 author: Vika Shleina co-authors: Graham Christensen -shepherd-team: TBD -shepherd-leader: TBD +shepherd-team: @samueldr, @Kloenk, @dhess, @grahamc +shepherd-leader: @samueldr related-issues: TBD --- From f1bb56ea0e74c3f4c0fef7ce44ce15be437cd644 Mon Sep 17 00:00:00 2001 From: Vika Date: Sat, 20 Nov 2021 17:51:28 +0300 Subject: [PATCH 16/16] Round of updates after the first meeting - Added suggestions on how to alleviate increased work on maintainers of critical packages in case of a platform-specific breakage based on prior art in RFCs - Added an alternative way to solve the problem discussed in https://github.com/NixOS/rfcs/pull/87#discussion_r590660269 - Added counterarguments to the drawback section discussed in the first meeting --- rfcs/0087-aarch64-tier1.md | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/rfcs/0087-aarch64-tier1.md b/rfcs/0087-aarch64-tier1.md index d6a939cfc..d0f1bf18f 100644 --- a/rfcs/0087-aarch64-tier1.md +++ b/rfcs/0087-aarch64-tier1.md @@ -51,6 +51,20 @@ to block channel advances. Hydra will start building aarch64 packages and run aarch64-based tests as part of stable and unstable channels, including them in the binary cache, increasing its coverage as a result. +A team for aarch64-specific build failures should be established (or, more +precisely, revived, as per [RFC0046](https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md) there should already be a team for ARM platforms called @NixOS/aarch64-maintainers) +to help track down and fix breaking changes specific to ARM platforms and be +at the front line of battle for ARM stability. + +Additionally, maintainers of critical packages (e.g. binutils) should be given +an advance notice before implementing the change to ensure no delays in channel +advances happen and no surprises occur, such as suddenly increased workload. An +option would be to ping them on the PR implementing this RFC and discuss it there +(and potentially delay the merge if there is any pushback). + +For help with testing packages on aarch64 for those maintainers who don't have +access to the machine, the [community build box](https://github.com/nix-community/aarch64-build-box) by @grahamc should provide a sufficient environment for running basic tests (and provide quick rebuilds using remote building). + ## Dealing with Capacity Issues [design-capacity]: #design-capacity @@ -83,7 +97,13 @@ The list of NixOS AMIs on NixOS.org will also be extended to include aarch64 ima # Drawbacks [drawbacks]: #drawbacks -Some build failures could unneccesarily delay channel advances, delaying critical updates. + - Some build failures could unneccesarily delay channel advances, delaying critical updates + - Already an issue on `x86_64-linux` from time to time + - We already run aarch64 tests on Hydra and they're mostly green - what's not green could be fixed if more attention is paid to those failures + - Maintainers of critical packages might not be ready for additional load + - Will there be additional load on them? Sounds more like already existing problems will float up to the surface and need to be fixed ASAP + - Potentially alleviated by reviving the aarch64-specific maintainer team and pinging it on all aarch64-specific issues not reproducible on x86_64-linux + - that makes `aarch64-linux` still sound inferior to `x86_64-linux` though... # Alternatives [alternatives]: #alternatives @@ -99,6 +119,11 @@ Elaborating on the previous alternative, create an aarch64-focused channel. Show there are enough resources and commitment to keep it green for half a year to a year. Carry on with the RFC topic once this is the case. +## "Just use your own CI" +Everyone needing `aarch64-linux` would then just track master on their own and build commits, +which would result in a lot of wasted work that could be saved by centralizing builds (which +is one of the reasons Hydra exists) and a lot of complexity for end-users. + # Unresolved questions [unresolved]: #unresolved-questions