There have been multiple calls for package maintainers, but the manual/documentation don’t seem to state what that entails and what rights one is granted when doing so. I can’t seem to find a process description where a maintainer fits in. There are a bunch of PRs done by non-maintainers that get reviewed and accepted by non-maintainers.
Most glaringly, IMO, being a package maintainer should give on the right to approve and merge PRs on packages one maintains (maybe github supports this with CODE_OWNERS or something?). That, however, doesn’t seem to be the case.
So, if one can get pinged for issues with a package but not merge fixes, upgrades, or improvements, what’s the point? Where does a maintainer fit in?
That’s a very relevant question and while people around here seem to have partial answers, it’s not written down as an agreed-upon authoritative statement in a central place.
For me, a package maintainer is someone who uses the software and can be there to verify that changes to a package improve it’s usage.
It’s hard to know from just a source updating whether a regression happens, or another issue.
In general, the more you help with maintaining (really reviewing) packages, the more likely you will become a committer.
Until we can introduce some machinery for fine grain commit access, the maintainer role is kind of limited, I agree. I would really like to see a system of a two-person sign off.
I’m not entirely sure if what I want exists. But it’s been discussed a few times that we need to make the maintainer role more meaningful, and unfortunately github (to no fault of their own, I can’t think of a ecosystem-independent solution) has course granularity on permissions.
I know that on gitlab it’s possible to set a minimum number of required approvals before a PR/MR can be merged. Maybe combining something similar on github with a CI action could work. The action could automatically merge PRs that reach some kind of quorum or some other (well documented) requirements. For example:
To me, becoming a package maintainer is a way to get notifications - issue templates ask people to ping the maintainers, ofborg requests for reviews, r-ryantm also pings the maintainers even if they are not org members. Issues for broken builds and outdated packages can go stale very quickly if nobody is pinged or immediately interested.
As a reviewer, approvals from package maintainers have a lot more weight, especially on less popular packages with only one or two maintainers. It’s a pretty easy merge when the sole package maintainer approved and diffs look ok on a package with 0 reverse dependencies.
If you are fixing or updating a package consequently you are essentially the maintainer for it and you can submit a PR to be added to it.
Why does that matter? If the package gets broken over time due to unrelated changes, you could be pinged to fix it or asked for help. Is there is no maintainer and the fox is none trivial, the package might be just named broken.
Also r-ryantm notifies the maintainers and if there are none the package might just be low tested or not tested at all updated and generally bit rot over time.
I think, it would be great if all PRs would require review from packages maintainers (in case of multi package changes or tree wide changes, some other rule would be needed).
The reason for that is the fact, that without deeper knowledge of the package and it’s related packages (it’s dependencies and reverse dependencies) it is very likely that your review is very naive and you are going to miss the context.
This leads me to another thing, which is creation of package maintainers teams. Ideally, packages shouldn’t be maintained by individuals, but by teams which are responsible for some set of related packages - for example Geospatial Team - for all geospatial packages (GDAL, GEOS, PROJ, QGIS, …). In this case, if you submit PR to any package maintained by the team, you can be sure that correct group of people will be notified and in case of simple changes review load is spread between multiple people knowing the package and can be very quick.
Another advantage of maintainers teams is better collaboration between people which are interested in the same thing. The can plan things and pre-discuss them, so they can be sure that their contribution will not be wasted.
This probably needs a bit more prominent representation. I wasn’t aware of this even after years of roaming around the code. Although I may not be representative, and don’t read the Nixpkgs manual too often.
Yes, I already created one team there.
But in current situation, usage, roles and responsibilities of teams and the process of creation looks even less clear then maintainers role.
So in summary, being a maintainer only provides responsibilities, but no rights nor privileges or special consideration. It is a service for the good of nixpkgs.
I think this should be added to the manual (maybe phrased better). At the moment this information seems to be missing from the manual. All I could find is
At the moment, to me there doesn’t seem to be much incentive to become a maintainer. I could as well be a user of a package, submit PRs when need be, and hope somebody reviews and/or merges the PR.
Stats on PRs like average time to merge and average time to merge with maintainer approval are not in my possession, but I’d wager the difference to be small to insignificant. And thus, having a maintainer status would only result in increased notifications.
I’d like to mark your post as the answer since it seems to be most succinct and informative one for me. It’s not possible for some reason, but thank you for the response.
Personally, as a committer, I give a lot of weight to a maintainer’s approval of a PR. Ofborg tags PRs approved by maintainers and those usually get merged very quickly.
Also, if the maintainer voices an opinion about how something should be done, I will go with that over someone else, unless it feels obviously wrong to me.
I also try to ping maintainers if they didn’t get pinged by a change to their package. So being a maintainer also gives you more chance to be notified of changes to a package. If you hang out on the stable channels, it should give you enough warning to try the package before it gets to stable under most timelines.
Another benefit of being a maintainer is your package can be included at all. We usually don’t let packages in unless there is at least one maintainer.
(This can’t have accepted answers since it isn’t in the Help category.)
Which is exactly why I’m maintainer of the six or so packages which I ‘maintain’: I wanted to use something on Nix, I did the (usually minimal) work necessary to make it possible, so I might as well contribute it to nixpkgs, and that makes me the maintainer. In the case some of these I suspect that I’m the only person who has ever used these on Nix … and don’t even use them myself any more.
So in summary, being a maintainer only provides responsibilities, but no rights nor privileges or special consideration. It is a service for the good of nixpkgs.
This doesn’t feel quite wrong, but I’m also not sure I agree with the framing. Yes, maintaining anything is more about responsibility than privilege.
But this is more about the package and nixpkgs than the maintainer.
~Leaf packages with no maintainer are at reasonable risk of being thrown out the window if they stop building. Some people will be leery of depending on a leaf package with no maintainer. Packages don’t have to have maintainers, but the ones with maintainers will (or at least should) get (relatively) special consideration in such circumstances.
But is that an issue? Does it have to come with privilege in order to be worth doing?
Free software “works” because enough people do their part. Most do very little and a few are basically super-human. Some are employed to do it and can obviously do a lot more than those who need to actively find the time outside of other commitments. But generally “we” do it because a project needs contributors (of which maintainers is one kind) to flourish.
You want to maintain software for the benefit of the community? That’s great - you will be welcomed with whatever is the online equivalent of open arms. But if you don’t think it’s worth it, that’s OK too.
Contributions to free software comes in many different forms and we need all of them.