I’m not sure whether this is simply perception on my part, or an actual reflection of reality, but from watching others maintain packages via PR, it seems rather onerous to be a package maintainer.
My point of reference: I maintain a number of packages in gentoo’s guru user repository. This is a second-tier of packages, not part of the core package set, but still an official gentoo project. There’s no real analog in Nix. I tend to describe it as “if the arch linux AUR had a core team of code reviewers merging things in”, but I don’t think that captures the culture of it either.
At any rate, as a contributor, I commit directly to the
dev branch. I had to apply for commit access to the dev branch, but it was a one time thing, and it was as simple as copy pasting some commands to generate some keys in a format they liked, and attaching them to an issue requesting access.
A project lead peridoically merges everything into the
master branch if things look fine. If they don’t look fine, they either leave me a comment on my commit asking me to change things, or they just make the changes themselves- no need to wait around for me. Other contributors can also directly make changes to fix my stuff, or I can fix theirs. It’s easy to see when I make a new commit to fix the problems they brought up since it’s all in the dev commit log stream.
They also will sometimes suggest changes but merge my build scripts anyway because they work fine, and the suggested changes are just nitpicks. I can go back in afterwards and implement those changes if I want, though sometimes I wait until the next version bump I do because I don’t have the energy at the time.
dev is the preferred method for contributing to that project; PRs are discouraged due to the additional overhead they introduce for the project leads, and the increased incidence of drive-by packages that come from PR with no extended maintenance to follow.
I’m not suggesting to apply this model to nixpkgs; I don’t think it aligns with what nixpkgs wants to be, but I want to compare it against my impression of contributing to nixpkgs.
From talking with friends who contribute, it’s my impression that maintaining packages in nixpkgs requires a lot more back and forth during the PR process to get a package into a state of sufficient correctness, even for version bumps. That it often requires pinging various people with commit access. That it can lead to duplicated effort when multiple people open separate PRs to bump the same package. And that what the state of “correct” is can seem unclear, and shift over time.
This impression has put me off from attempting to contribute to nixpkgs, so I do not have personal experience to go off here. In particular, I’m not interested in contributing a package and then leaving it to rot; I want to continue to maintain it. But I only have so much energy to put towards that. So while I’m fine with a high degree of friction introducing a new package, I’m put off by the notion that I might have to interact with that same level friction every time I update the package too.
From a technical perspective, I also find that bumping a package with a lot of hashes that need changing in the nix file can be incredibly taxing, as I need to re-run the build and update them one by one, hash by hash. I’m not aware of whether others have scripted this away into something I can run to update everything (would need to support language-specific things like
cargoLock.outputHashes since that’s where I have the most trouble). I think this is a lower barrier for me than the rest, but it is a factor.
I do contribute in other ways, primarily through blogging, as well as existing ambiently in the exotic targets channel and working to be thorough when investigating bugs with others there.