First of all, I am extremely grateful to the wonderful community of maintainers who have created the best package management and configuration ecosystem I’ve ever experienced!
However I sometimes come across NixOS and especially home manager modules where the maintainers seem quite out of touch with the upstream package they are maintaining. E.g. options are implemented in ways that are counterintuitive and sometimes counterproductive to upstream users. Sorry for being vague, but my intention is not to call out any individuals here.
I’m just wondering what to do in these situations? Usually I just grab the package and ignore the module in such cases and move on. What do others typically do and what is advisable?
The #1 rule (IMO) is to be the change you’d like to see in the world and PR the fixes. If they get accepted but require a breaking change, it makes next release with a changelog. If they aren’t accepted, go out of tree and expose the module yourself.
IMO one should first create an issue and get some directional alignment with the maintainer before submitting a PR, but I’ve often found such maintainers to be non responsive to issues even when using maintainer tags.
I guess it also doesn’t help that the repos and issue boards for our repos are so large that issues for individual modules are hard to surface.
I honestly think it’s fine etiquette to propose a code change if it gets ignored. Worst that happens is they say no (or it gets buried) and you make a GH repo with a module that people can just load instead, right?
From my experience, maybe depending on the amount of rework, having something to discuss over (so code) is much easier and productive then paraphrasing.
Due to this, my view is that I prefer to create and receive PR for reasonable changes directly.
If a change or parts of it might need discussion (so that I think it should be discussed), I start commenting those proactive to point to that areas.
If something is so controversial that a PR does not make sense, the change idea itself is often not a good idea (at least that’s on my ideas).
For those things I am playing around off-tree first to let ideas “harden".
Personally I create Issues just if I want to point something out to improve but are either not at a skill level to solve it (e.g not familiar with the language, project structure etc and not willing to invest into learning here) or just don’t have time right now to suggest a solution to issue.
Projects that require me to create Issues before doing PRs I am leaving quite fast again, as from my perspective it’s just useless paperwork to create.
If modules are poorly maintained with the reasons you mentioned, it’s likely that the maintainers are overloaded anyways or they left the scene.
Then IMHO it’s best to pick up the modules and give them some love to improve the situation for everyone else too.
Tbh, I suspect this is the root cause of the problem. Maintainers have checked out of the project, but they don’t want to admit that, and there’s no clear mechanism to hand over the reins to someone who is more invested in the upstream project.
@Shawn8901 summarized my view quite well! For any straight forward fix I always prefer receiving a PR that is locally tested and as soon as the questions to answer are to many and the amount of work is to much for a quick evening fix, just try to get in contact or ask on Matrix or what makes sense in the moment.
I think you overformalize and/or overestimate here what being a maintainer in context of nixpkgs and connected tooling (often) means.
For nixpkgs content you become a maintainer when adding your handle to meta.maintainers of said package or module. That’s it! The effect is that you get pinged automatically on PRs and often on issues (as you are listed as maintainer), but you will anyways not be able to merge PRs in that area as you need commit permission for that. [ to be very correct, in nixpkgs you can merge PRs from r-ryantm (update bot) and those from commiters via the merge-bot, those that are mergable by bot have a label “2.status: merge-bot eligible” set].
The same applies here for home manger modules as far as i can see (so becoming a maintainer) but for being home manager maintainer is can not judge to much, as i do not maintain any HM module (yet).
But on nixpkgs i haven’t seen an occurrence in nixpkgs where adding more maintainers was an issue an existing maintainer, if there has been some i have missed that. Often they suggest to add yourself as maintainer when creating few PRs in that areas to help maintaining.
Being a maintainer helps the other maintainers and commiters (those are two roles!) to judge that you are interested in the result and have an intrinsic motivation to have the part (package or module) to be working and in a good shape and that you also likely know how to test the basic functions.
As said, because there is no real special power attached for being a maintainer i honestly personally don’t see why there should be a “handover” needed here if people are fading away their interest. And a lot of packages and modules in nixos context have multiple maintainers, so there is no single point of contact for handovers.
IMHO it would just be an extra step in bureaucracy that likely has no productive effect.
I mean it would be nice to off-board people, so that its more clear that the maintenance is abandoned, tho that is a different story on my opinion.
This is a pretty good way to look at it. nixpkgs is very much a “do-ocracy” where people get busy, life happens, etc. The maintainer label is mostly just a point of contact for who “owns” that thing at the time when the reality it’s that it’s the aggregate of all the improvements everyone PRs over time that make things usable.
maintainers seem quite out of touch with the upstream package they are maintaining
Maintainers come and go, and whoever added the package first sets the tone. The rest of us (200-250 active maintainers at last count) do our best to keep packages updated and working; modernizing option settings (for example) often falls behind. (We also try to minimize disruption.)
If we’re lucky, we get a maintainer who wants to “own” a particular area (ex: I maintain langchain and langgraph, and I coordinate with upstream to fix issues). If there’s not a designated maintainer, everybody helps out.
We’re always open to new maintainers and we provide a lot of support.
P.S. If you wanted to make the home-manager options consistent, I’d start by opening an issue with your proposal and discuss it with the home-manager maintainers. I think you’ll find us to be a helpful crew.
Thanks for the encouragement! I’m not talking about home-manager itself, but about individual modules within home manager (where you need to understand upstream and translate to home manager options). As I mentioned I’ve tried opening issues and tagging the maintainers of the modules, but often haven’t gotten encouraging responses. Following the advise in this thread, I will try to submit PRs instead!
Had this issue with OpenCode - the module was always stale, many builds behind. We (a bunch of anonymous dudes on discord) worked together with the OC team to help them make their own flake, auto-updating on each build, and nixpkgs be damned
Just gave me an idea: it’s pretty bad for discoverability and work duplication, that there’s no process (afaik?) to “supersede” an abandoned/outdated nixpkgs package with (at least?) a link to such a (de-facto more “official”) solution.
I wonder if such a process is feasible to implement (and in what way), so that one could basically “prune” nixpkgs of obsolete packages and refer to the de-facto upstream (flake/overlay) instead. Not sure how this extends to non-flake though.
Maybe it’s even conceivable to automatically extract package derivations from upstream flakes and generate corresponding nixpkgs for them?
Not sure if that is a healthy solution for the nixpkgs eco-system (in perspective how it currently works as it’s very centralized in perspective of code).
If there are packages or modules unmaintained/abandoned so that they are not usable, feel free to create drop PRs for such things.
But if you plan anyways to build and use for this kind of software, it might be a good solution for all.
If the issue is to frequent updates, you might want to chat with some commiters, to volunteer so that PRs get merged quickly.
It’s actually been a lot better for months now, since @khaneliman has been reviewing/merging stuff. Simple changes have often been merged the same day. I’ve been very thankful for his work on Home Manager.
