.github/CODEOWNERS

[ghost]

I enjoyed doing major overhaul work on these parts of the codebase, but the unfortunate reality is that they are upstream of a ton of nixpkgs code. The current nixpkgs development model encourages the insertion of lots of random stuff into upstream packages by downstream development. This means that the more stuff is downstream of your work, the faster it will bitrot inside nixpkgs. I've tried to take responsibility for cleaning up these cruft accmulations.

Unfortunately this means that my first interaction with most people is either pushing back against the cruft or cleaning it up (which often feels like a revert).

I try to be polite, and certainly need to try harder, but it will always be the case that this puts me in a position where my first interaction with most people is at least mildly negative.

I don't want to be in this position anymore.

It is not a good way to win popularity contests. It also interacts badly with the way various committees form their opinions: they mostly seem to tally the number of times they've heard somebody's name in a negative context, without a weighting factor or even a denominator.

• cc-wrapper: revert speculative commentary #282210
• cc-wrapper: relocate proprietary-compiler-specific material #282220
• Discussion with amjoseph #282862

---

Stepping back, I think we're operating way, way, way beyond the design limits of the Nix language. It shouldn't take this many people to do what we're doing. Guix covers almost as much ground as we do with 1/10th the developers -- and IMHO Scheme is a step backward from Nix.

A smaller, lower-churn dev team would mean not having such frequent cases of "Hey this is our very first interaction. I need to point out the mess you made, hope you clean it up, and then if not clean it up myself". It's way easier to have those sorts of discussions in a diplomatic way when you have history with the other person. Having that be your very first interaction with multiple different people is extremely draining.

[7c6f434c]

I do think Guix is covering less ground in a sense that matters for efficiency, in the sense of being more usecase-cohesive. Also, in making the main repo not care about non-free stuff, in particular not having macOS at all, but also CUDA only in a separated downstream repo with no direct influence on the upstream.

[RaitoBezarius]

Thank you for your work on all of that, I really cannot understate the tremendous work you have done in nixpkgs and I really enjoyed it too.

[lovesegfault]

You've done heroic work, thank you.