This is a really good point and has changed my view on some recent-ish controversies about other maintainer conflicts of interest. I’d love to see consensus around making explicit the responsibility of Nixpkgs maintainers to be user advocates, because I agree that it should be, and as a consequence we should probably avoid overlap between upstream authors and maintainers when possible.
18 Likes
Yes! Even more so in the current software era where so much software is actively predatory (this is not specifically to say that this upstream change was intended to be, but the reaction to that change is stronger because of that current climate)
7 Likes
I don’t think this would really have done much even in this specific situation. The version update to 1.4 was merged with approval. The DO_NOT_TRACK flag was probably added based on the changelog not by reading the code. Only after the controversy about the do not track reversal arose did people even look into the code and find out that devenv was uploading repos wholesale.
3 Likes
If the maintainer is separate from upstream, chances are a bit better that they might actually check the code. Upstream already knows in detail what the changes are, and the conflict of interest means that they are less likely to reset and try to perceive those changes from a users’ perspective than a third party maintainer.
In this case there was basically no chance, domen themselves said it, working on a feature for over a year and then not seeing the tree for the forest is a very human thing to do.
No guarantees that this solves everything, of course, but just look at debian to see how effective upstream != package maintainer can be at keeping upstream honest.
The downside is increased maintenance burden and more bikeshedding. But it’s a worthwhile consideration.
9 Likes
This is drifting a bit of topic, but, with the way things are going in nixpkgs, things like this will happen more often in the future. The trend towards more automation in package management in nixpkgs will undoubtedly lead to fewer humans in the loop. In a year or two, a bot will probably just have bumped and merged the version without a human even noticing.
6 Likes
Perhaps we need attributes (either in nixpkgs or an external dataset) indicating how much human review each update has had, and by who? If one want to really (over-?) engineer, perhaps something like GitHub - crev-dev/cargo-crev: A cryptographically verifiable code review system for the cargo (Rust) package manager. but for nix?
One could could perhaps also categorize packages by the importance, with the most critical / widely used aiming for a higher degree of scrutiny?
1 Like
I think nixpkgs already struggles to review changes promptly and we should be conservative about adding new duties to the maintainers, or making it harder for package authors to maintain their own code.
It’s easy to say “maintainers should be user advocates” but given a fixed supply of maintainer labour we should think about this as “they should do more of this work and less of their current work”. (Plausibly still worth it, but not something to say quite so lightly)
8 Likes
I think of this less as a change to the maintainers’ work load and more as a change to the standards by which we qualify and evaluate maintainers. I wasn’t proposing that maintainers do extra work like, I don’t know, circulate a survey among users in order to evaluate PRs. What I had in mind was more that when a maintainer is fulfilling their existing ‘is this a good change’ responsibilities, we should direct them toward answering that question with a bias towards what users are likely to want, when that is in conflict with what upstream may want. Codifying that guidance may even make maintainers’ jobs easier.
I’ll grant you that it may be harder to find maintainers if we expect them not to have a conflict of interest with upstream in light of that direction, which is why I had the ‘when possible’ qualifier in my post—probably an upstream-maintained package is better than an unmaintained package. But an independently-maintained package is better than either, and we should aim for that.
4 Likes
Lots of important packages have no .meta.maintainers even now or those in there aren’t reacting. Just felt like pointing it out. I personally find that more important than these conflicts of interests.
9 Likes
The aim should be to establish processes that lead to an agreed on best practice. Right now a maintainer can make an effort to override other opinions on telemetry. If a best practice (or code of conduct or policy) is established a disagreement between nixpkgs contributors could be dealt with in relation to these norms.
I think the following should be done:
- mark packages that have telemetry.
- establish a way to block the installation of has-telemetry marked packages. (like it is possible with unfree)
- establish a policy about the preferred package configuration in regard to telemetry in nixpkgs.
- establish processes to enact the policy.
3 Likes
How can the speed of the review process be a problem while at the same time the review process has produced the Linux distro with the most packages? Am I missing the trees for the forest or are we trying to maximize throughput without regard for users?
4 Likes
Because the speed of the review process itself isn’t the only overhead, and it can be amortized. Nixpkgs’ dominance stems largely from bulk-importing various ecosystem’s packages, which is not considered appropriate or necessary in other distros.
Last time this discussion came up it became apparent Arch was still well ahead if you exclude those packages as much as is possible to assert - and nixpkgs is much closer to the AUR in average package quality, which is excluded from those metrics. I’d be surprised if the needle has shifted much since (though it will have a little, plenty of new folks pulling their weight around).
Automation also helps, which nixpkgs is uniquely good at because nix and hydra are amazing, and nixpkgs’ (implicit?) policy of staying close to upstream makes the process of packaging much simpler - all things that help create a large number of packages in spite of issues around the review process. Nixpkgs being hosted on GitHub is probably not a small contributor, either.
Those metrics do not imply that review and maintenance overheads for individual packages are unproblematic. I’ve been discouraged by how long it’d take to fix something plenty of times now, and it’s hard to find people to bounce ideas off that’d otherwise get the ball rolling on improvements - it’s common to see packages lie around unmaintained because nascent package authors became frustrated and burn out.
That said, merge overhead has always a problem in every software project I’ve been part of - it’s kind of a “problem” by design. If there’s anything to be done about it, I think nixpkgs is biting off too big of a chunk for its contributors to handle, reducing the number of packages in a “core” set would probably be great for the health of the project.
7 Likes
Endorsed. It also means that niche packages will likely not get uploaded for a very long time, if at all. Likely net effect: instead of contributing to nixpkgs, commercial packages would end up in proprietary flakes and probably not get as much attention as devenv did. I do not ship proprietary software to the public through Nix, and personally I’ve already stopped upstreaming the Free Software I write or niche packages I use into nixpkgs. They just go into a personal flake that provides an overlay, and get imported into my NixOS config from there.
1 Like