[pre-RFC] maintainer-list: add raitobezarius supportedArchitecture

[RaitoBezarius]

Description of changes

Inspired by #250344 (comment)

Here, I suggest what architectures I commit to maintain for my own packages.

I suppose we would like to move this in this way:

maintainersPerArchitecture = {
	"x86_64-linux" = [
	   raitobezarius
	   ...
	];
   ...
};

to avoid repeating so much text.

What do you think of the idea?

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[RaitoBezarius]

Feel free to hijack this PR for any exploration as long as you coordinate with anyone, I opened this to foster discussion.

[RaitoBezarius]

Adjacently-related to Darwin issues that @piegamesde reported.

[JulienMalka]

Does that mean that you are fine with breakages of your packages for architectures outside of this list ?

[RaitoBezarius]

Does that mean that you are fine with breakages of your packages for architectures outside of this list ?

I'd say, it communicates more that I cannot really commit to anything outside of this list. Not a lot of people can commit to fix a package for the Knuth architecture anyway on a daily basis.

[figsoda]

2 suggestions i have

• architectures -> platforms to be more consistent with meta.platforms, also architecture is sometimes referred to only the x86_64 and riscv64 part, but not the kernel
• limitedSupportArchitectures feels a bit arbitrary and verbose, having a list of list allows users to have more than 2 tiers of support

Suggested change

	supportedArchitectures = [ "x86_64-linux" "riscv64-linux" ];
	limitedSupportedArchitectures = [ "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ];
	supportedPlatforms = [
	[ "x86_64-linux" "riscv64-linux" ]
	[ "aarch64-linux" "x86_64-darwin" "aarch64-darwin" ]
	];

[RaitoBezarius]

limitedSupportedArchitectures comes from nixos/release-*.nix BTW.

[AndersonTorres]

Platforms follow the tier system. We can replay them here somehow.

[infinisil]

That doubly-nested listing is rather hard to understand, and I don't think we need to use the same tiering from NixOS/rfcs#46. How about

primaryPlatforms = [ ... ];
secondaryPlatforms = [ ... ];

Or maybe this would be better, more directly correlating to the expectations:

# Using these regularly
regularPlatforms = [ ... ];
# I have these available if necessary
availablePlatforms = [ ... ];

[7c6f434c]

Maybe even primary/available. I do use a bit of Nix-managed stuff on aarch64-linux daily… but really not enough to have primary-platform competence there.

[piegamesde]

How about primary/supported? (Maybe with a check that the former is a sub set of the latter (Speaking of which, that maintainers list doesn't seem to be type/sanity checked anywhere?))

[figsoda]

I like primary/supported and primary/available, though I wouldn't repeat the primary ones in supported/available.

[infinisil]

I like the general idea! Though just adding such entries doesn't really do very much, it needs to come with something that actually uses them. For example if we had email notifications working for broken Hydra builds this would interact really nicely with this. Other than that, how are you thinking of using this?

[7c6f434c]

Other than that, how are you thinking of using this?

The first use I see is that if something is broken on macOS and has a less-active maintainer with macOS as primary, one can try @-mention them in some useful and descriptive way, otherwise it goes to platform team (with lower expectations of success)

[RaitoBezarius]

I like the general idea! Though just adding such entries doesn't really do very much, it needs to come with something that actually uses them. For example if we had email notifications working for broken Hydra builds this would interact really nicely with this. Other than that, how are you thinking of using this?

Actually, even the existence of those entries can go quite far to inform maintainers to what to expect from other fellow maintainers, without any automation. Plus, step one, is getting the metadata right before writing any automation, IMHO.

This is a classical problem in nixpkgs contribution when someone is blocked on a PR because they do not have Darwin machines, and they cannot fix the problem at hand that CI says "this is broken", sometimes, this can also end up being a rabbit hole in Darwin internals because someone does not know how to fix it.

To give a clear example, I do not expect any x86_64-linux maintainer to know a fair deal about how macOS frameworks work, though, sometimes when there is a breakage, you have to fix it using that knowledge.

Moving forward, as a release manager, I need to be able to understand if I can rely on someone to fix something for a specific supported architecture, sometimes, it is not possible to find a Darwin or aarch64 maintainer for something, this field would help me to ping the right people.

Moving forward again, OfBorg can eat this metadata, nix-eval-jobs can eat this metadata, this can help to detect brittleness when it comes to maintenance, etc. For ZHF, this can further improve the list generation of maintainers to avoid listing people who won't be able to produce any effort towards a specific architecture breakage.

[zimbatm]

I like it; it's moving in the right direction. This will become more useful once the tooling takes it into account, but it's a chicken-and-egg problem.

[JulienMalka]

I think this idea is interesting. I'm simply afraid that some people will interpret it as a moral pass to disregard other architecture. I still think that whenever merging a change breaks an architecture for a package, it is wished that the maintainer does it best to see if the breakage can be fixed.

[7c6f434c]

A push that maintainers should do more about platforms they don't care about is a push towards maintainers actively opposing adding platforms.

[AndersonTorres]

a moral pass to disregard other architecture

Sometimes I feel inclined to disregard other architecture when this other architecture is Darwin spending 20 days on ofBorg.

[zimbatm]

This is going to make these things more explicit. We're all hoping for goodwill, but we can't force people to maintain architectures they don't control.

[RaitoBezarius]

Now that we kind of agree on the intents and goals, I think, we need to discuss how to enrich the existing data.

My idea is that we will have folks who won't be able to declare their "primary/available" architectures, therefore, we will have a period of incomplete metadata. Though, we need to coordinate pinging everyone to add their metadata somehow.

I believe we only need to design the way to add yourself in the lists, I don't know if we want to have denormalized or normalized lists for that, e.g. a list of maintainers per platform primary/available, a maintainer that contains a list of architectures. Open to ideas here.

Once we get the design right, fix the type checking, add a script to know who is missing for the metadata (i.e. a maintainer with no primary platform), we can have a mergeable prototype IMHO?

Then, I would suggest we can open up work on exploiting the metadata, be it for ZHF, or our own PR automation, etc.

Would this plan make sense to you, folks?

[SuperSandro2000]

Here, I suggest what architectures I commit to maintain for my own packages.

I'd imagine that people would want to define this per package. Some package groups are easily maintained cross platform and others are very hard to.

[RaitoBezarius]

Here, I suggest what architectures I commit to maintain for my own packages.

I'd imagine that people would want to define this per package. Some package groups are easily maintained cross platform and others are very hard to.

This seems overkill for the first design. The metadata is not supposed to reflect perfect information.

[7c6f434c]

Some package groups are easily maintained cross platform and others are very hard to.

Erm, if a package is easy to maintain on a platform where you cannot even run it to test, that sounds like the platform list for maintainers will never be looked up because it will work or break on all platforms together?

Sure, there are some exotic cases, but I guess we can start with putting comments in the relevant packages, and once there are examples, they can be considered for v2.