Add AARCH64 channels for NixOS 20.09

[andir]

This adds a channel for NixOS 20.09 on AArcch64 based on the hydra
jobset that we already have.

The topic of an aarch64 specific channel has come up regular and as
these devices are gaining in popularity will only be discussed more
often.

This had been discussed on the nixpkgs issue tracker: NixOS/nixpkgs#83049

[grahamc]

I would strongly prefer making aarch64-linux a supportedSystem in the regular 20.09 channel, allowing the one channel to serve two architectures so systems of mixed architecture can be on one commit. Is that feasible?

[andir]

Sure that is feasible but a change in release scope and would likely cause unexpected channel blocker in the current release. This topic has come up so regulary and there had been almost no response from those in charge of hydra that I just decided this would be the best move for now.

[andir]

As for newer releases I think we can add that to their scope - if we feel like it. I don't know what how decision making there is supposed to work. Who decides that? Do we need an RFC?

[grahamc]

I think we would need an RFC, to move it from a tier-2 to a tier-1 platform: https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md

[grahamc]

which, btw, I'm totally in favor of doing.

[andir]

I think we would need an RFC, to move it from a tier-2 to a tier-1 platform: https://github.com/NixOS/rfcs/blob/master/rfcs/0046-platform-support-tiers.md

Yeah. I am out. No time & energy for that process.

Going by the current channels and jobsets it seems like being Tier1 is not a requirement for either of them. In fact that document describes that the Tier2 platforms have channel blockers. Yet we have no channel. The approach suggested here seems to be easier and might also be in line with that RFC.

[vikanezrimaya]

aarch64 becoming a tier 1 platform sounds very exciting! I'm somewhat in favor of aarch64 blocking the main channel (because then it'll be easier to have everything on one commit) but my voice shouldn't have too much weight in that particular regard because I am myself using flakes and usually just manually pick whatever revision I need (since I also maintain a nixpkgs fork and updating for me includes rebasing my branch on top of nixos-unstable every time I want to upgrade).

I feel like my involvement in NixOS is increasing though, and I feel like I might be ready for filing (or helping to file) an RFC for that. I read some RFCs before and it feels like something I should be capable of, so I guess I should start right now?

[vikanezrimaya]

And... done. I hope I did everything correctly, and I will be glad if someone agrees to co-author this with me, extending the manuscript with things I missed (there are probably things that I missed, please at least do tell me what I missed 😨).

[samueldr]

I would strongly prefer making aarch64-linux a supportedSystem in the regular [...] channel

Last time this was tried was before the rewrite of the hydra evaluator. At that time the hydra evaluator wasn't able to cope with the added packages.

We might want to, in parallel, try it once in a throwaway hydra project to see if it is still causing issues or not. So we can get the fixes in parallel to the other "social" changes.

[grahamc]

Note also that nixos-unstable already blocks on aarch64-linux.

[samueldr]

NixOS 20.09 also already blocks through the same mechanism IIRC

https://github.com/NixOS/nixpkgs/blob/505c9d253dcc9b1cb51697207c4218024cb5d818/nixos/release-combined.nix#L8

The whole package set is not tried to be built in the channel, but some artifacts end up building a chunk of the basic closure.

So in a sense, it has been working this way for two full years including their stable releases.

• NixOS/nixpkgs@1bfe8f1

[vikanezrimaya]

what does it mean for the RFC tho

[grahamc]

My impression is at this point aarch64 is halfway between tier-2 and tier-1, and this RFC is clarifying and completing that transition between tiers.

[7c6f434c]

Just in case, as an, ahem, an active participant of the discussion of the RFC mentioned here, I am pretty sure that promoting aarch64 to full Tier 1 is supposed to be a complicated process (because it needs to move expectations in the PR review process, which is the hard part in our project).

And that means that merging this PR today makes perfect sense — it just improves aarch64-linux tooling for now, without creating much new burden on Hydra or any process burden on other platforms. And «proper» upgrades towards Tier 1 will take a couple of forevers, so it's good to have what we can have cheaply.

[andir]

Updated the PR for 21.05. I still don't think we need to move the platform to a higher tier in order to add a channel for it.

[grahamc]

I don't see any reason to not do this, other than a potential cost of confusion if we were to continue adding many channels for many different use cases We should probably use this PR as a learning experience and improve the "how to do a new architecture" flow with what we've learned.

[grahamc]

Deployed.

[7c6f434c]

I don't think we can have a «how to do a new architecture» flow above Tier 3, because small details in context can have unreasonable influence on the events (see aarch64-darwin…) And of course each of the architectures worth such a discussion will be important for its own and unique reasons.

I am not sure too many people would succeeed at telling how many channels there are, so the confusion might be somewhat limited. Maybe discussing a good way to present the choices so that we can add more channels based on things that are built anyway could be useful, though!