Aux is growing and we need to put together a set of contributors responsible for maintaining darwin packages. If you want to help, please reply in this topic with the following information:
Reason: (why do you want to be a darwin maintainer for Aux?)
Experience: (examples of past experience maintaining packages)
Just wanted to say I’ve got a Mac M1 and x86. I can get XCode stuff and test things, but probably won’t have time or real skillset to debug llvm or libc stuff.
Reason: I like using nixpkgs on MacOS
Experience: None for NixOS packages. I maintain about 20 JS and 20 python and 20 VS Code packages.
I’m pretty much on the same boat as @Jeff.
Reason: Somebody will have to maintain macos nixpkgs, since I use macos I guess I would end up doing it on my own if aux project doesn’t support them because of lack of interested people.
Experience: None in nixpkgs. I maintain derivations for a couple of internal perl packages at work.
I would love to be a maintainer.
Reason: I want to have a package ecosystem where updates and news packages get added at a good pace, which isn’t the status quo at nixpks.
Experience: yes! I am a member of the NixOS foundation on GitHub and have made numerous contributions to the Darwin packages there.
Awesome! I’ve set you as an owner for the SIG Darwin group. Looking forward to collaborating!
What will the organization look like on GitHub? Are we holding off on adding people? And what about contributions to packages? Is it a good idea to start?
The organisation exists, auxolotl · GitHub. To join make a post here GitHub Organization Membership.
Here is a good place to start reading in prep for the hard fork. SIG Repos: How should they work?. In the mean time we are following a soft fork workflow where you contribute to GitHub - auxolotl/nixpkgs: Nix Packages collection & NixOS like you would for nixos/nixpkgs.
Do you mind expanding on this?
I meant specifically for contributing to the Nixpkgs fork. Is it a good idea to start opening PRs for adding/updating packages or should we hold off on it?
Right now we want our changes to the nixpkgs fork to be as minimal as possible, only making them when necessary for the project. Most of the reason here is due to not having CI and caching.
Starting to pull out and manage packages in separate repositories is a good experiment to do right now. This will keep the scope of builds down and also let people iterate faster on ideas.