maintainers/team-list: establish the Darwin team #348183
Conversation
nix-owners
bot
requested review from
infinisil,
LeSuisse,
mweinelt,
philiptaron and
risicle
| @@ -21,6 +21,14 @@ | |||
| - pkgs/by-name/ne/nemo/**/* | |||
| - pkgs/by-name/ne/nemo-*/**/* | |||
|
|
|||
| "6.topic: darwin": | |||
There was a problem hiding this comment.
I'd suggest removing the darwin label from ofborg if it is going to be added here, ofborg adds it based on the PR title but the action will remove labels that don't have a path match.
There was a problem hiding this comment.
Oh, that’s a shame. Do you know if there’s any way to get both of them to cooperate? Maybe we should just drop this commit if not, although I think ofborg’s heuristic isn’t particularly great.
|
A thought that I, naturally, had right after putting this up: perhaps @NixOS/darwin-team would be the best name for the GitHub team, as the name maps unambiguously to |
| @@ -197,9 +197,10 @@ with lib.maintainers; | |||
| members = [ | |||
| reckenrode | |||
| toonn | |||
| emily | |||
There was a problem hiding this comment.
A minor nitpick, but you should be at the top to preserve the order. (Otherwise, I wouldn’t have added myself first if I weren’t alphabetically ordering the members list.)
macOS support in Nixpkgs goes back a long time; I’m not sure exactly when it was first added, but some degree of support was around in 2004, with a revival in 2009 with the addition of
x86_64-darwinsupport. Being able to build packages and development environments across platforms is a big value‐add for Nixpkgs and has gained us many users and contributors that we otherwise wouldn’t have had, but its path from fun experiment to officially‐supported platform used in production by many people has been a rocky one. People who have looked at PRs from years ago will recognize names like @copumpkin and @matthewbauer that put in tons of incredible work to establish the pure Darwin build environment that we’ve been using since, but they moved on to other things, and the platform suffered for a long time from a lack of active maintainers with the ability to keep up with changes in both Nixpkgs and macOS.When the first Apple Silicon Macs were released, @thefloweringash went to great lengths to establish support in Nixpkgs for the new platform, finally adding the macOS 11 SDK and making a lot of tooling and improvements. For the past three years, thanks to @domenkozar and @toonn, we’ve been calling for people to join @NixOS/darwin-maintainers, which has made an immense difference to the state of macOS support in Nixpkgs thanks to helping out with porting derivations, testing packages, and fixing builds. However, the bedrock of platform support that work has built upon hasn’t fared so well – I’m sure everyone involved knows the pain of packages needing a newer SDK than we’ve had available, or having to tell people to clutter their derivations with baroque framework dependencies and
overrideSDKnoise, not to mention the pain of Rust packages that need a newer SDK or the state of ofborg Darwin builds.That’s finally starting to change, and we’re now at a point where the core Nixpkgs Darwin infrastructure is seeing great renovations and improvements. @reckenrode’s long‐awaited SDK rework has finally landed; it adds the missing SDK versions, makes them much easier to use, gives us a build environment more like Xcode’s, and means we’ll never have to specify explicit framework dependency lists again. It will vastly simplify the experience of building packages for macOS, and far more things should just build out of the box. It’ll be available in time for 24.11 after the next
stagingcycle; documentation is being worked on, but take a look at #346043 (comment) and #347216 for examples of what a difference it makes. We’re also going to raise the minimum macOS version for 25.05 and track closer to what Apple and other FOSS projects support in future, sox86_64-darwinwill stop being such a problem. (And I plan to try and solve the Darwin ofborg problems soon.)As a result of all this activity, it makes sense to establish a fully‐fledged Darwin team to take responsibility for the core platform support infrastructure: the standard environment based on LLVM and cctools, SDK packages, Apple source releases, and other critical components that are used across the tree on macOS. I’m really happy that we’ve managed to get people pinging @NixOS/darwin-maintainers when they need help, but of course, not everyone who signed up to help out with packaging software on Darwin wants to be held responsible for maintaining arcane internals like these, and not everyone who would be interested in maintaining this infrastructure wants to get the volume of pings that the existing GitHub team gets.
It makes sense, therefore, to decouple this new Darwin team from the existing @NixOS/darwin-maintainers and assign a new GitHub team to
lib.teams.darwin, which hasn’t corresponded to the GitHub team member list for years anyway. I’ve created @NixOS/darwin-core for the purpose, added it to the teams and codeowners files in this PR, and will request the organization owners assign it to the Nixpkgs repository. I want to be clear, though, that this isn’t a matter of creating a hierarchy. If anything, we’re here to serve @NixOS/darwin-maintainers, by maintaining the core infrastructure to make creating and maintaining Darwin packages as smooth as possible. We had some discussion about potential names for the new GitHub team and even possibly renaming the existing GitHub team, but we didn’t come up with anything that I thought was clearly better, and I don’t want to throw away the work we’ve done teaching people to ping @NixOS/darwin-maintainers if they have a Darwin problem. I’m happy to bikeshed further if anyone can think of better names that more clearly delineate the roles of the two.We’d also love for more people to get involved! I’m only adding myself in this PR, but I talked with @paparodeo who also expressed potential interest in joining, and I know there are other people who have done work on Darwin platform support who I think would be a great fit. If you’re interested in doing and reviewing work like the following to improve the fundamentals of macOS support, it’d be great to have you:
(Although hopefully we’ve done enough foundational work by now that the PRs won’t be quite as big as some of these going forward!)
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.