until the day r-ryantm is merged by a committer without your knowledge - confirming you are basically a ghost.
1 Like
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.
BTW, I already created issue Create the process of establishing new teams in NixOS Foundation repo.
1 Like
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.
2 Likes
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.
Cheers
1 Like
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.)
8 Likes
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.
2 Likes
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.
7 Likes
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.
13 Likes
Honestly, I would love to help, but I find it difficult…
I did maintain a few Fedora packages, but the process was quite different to become a package maintainer compared to NixOS / Nixpkgs.
- Fedora Documentation
- Packaging Guidelines & Getting Started Tutorials
- Minimum of 3 packaging reviews (3 PRs in Nixpkgs would be the equivalent) on different packages from different languages (Rust, Python, C, C++, etc)
- Package maintainer sponsoring someone who has proven themselves and understand the process.
The problem I’m facing is I would love to contribute, but where do I start?
Do I need to build the whole nixpkgs repo, or is there a way to bootstrap this process (mimic the nixpkgs repo) to package a library / program before submitting a PR against nixpkgs repo?
Is there official documentation or guide where newcomers can read and understand on how to become a package maintainer / create proper PRs?
Becoming a package maintainer in nixpkgs doesn’t require any packaging reviews, but also doesn’t give you any privileges or authority. Your decision might have more weight to the committers, but that’s more implicit.
CONTRIBUTING.md and the Contributing to Nixpkgs section in nixpkgs manual are things you would want to read. There are other less well-documented things/conventions that you might be able to learn from the reviews over time.
You don’t have to build the whole nixpkgs repo - you just have to make the changes and build/test the package(s) you created/changed/affected. CI will be able to catch some common errors once you open the pull request. nix-init and nix-update are tools that can help you in this process.
6 Likes
If you want to contribute, you can follow the manuals and guides already provided above.
My personal recommendations is the unnofficial guide from Wiki: Nixpkgs/Create and debug packages - NixOS Wiki
Unfortunately our docs are not too user-friendly when compared to other distros. However, I believe they are comparable with the “nearest competitors” in this regard, namely Gentoo and Arch.
About comparing with other distros, Nixpkgs is very friendly about new contributions. I have tried to contribute to other distros and they are too bureaucratic IMHO. In Nixpkgs you can just fork and PR - and wait to be roasted (usually by me in a bad day).
If I had to maintain cars, servers, plumbing, wiring, or what have you, for a living, I would require the ability to execute, not only acknowledge, advise, and plan. Review is of course important and I’d go as far as say it’s an absolute necessity for a project like this (meaning pushes to master or merges without reviews should be banned), so I’m not equating maintainers to gods/admins/root users.
My point is: maintainers should be committers and all committers should:
- at least have their work checked
- ideally be code owners
This is not a question of worth at all. It’s not my concern. This is an anonymous account not tied to a real name that, so I can’t even put it on a CV. What I do care about it bottlenecks or suboptimal processes. Right now the process is:
- create PR
- wait for maintainers to respond (if there are any since owners or maintainers cannot always be identified)
- timeout → request a review on nixos discourse (one has to even know about this option)
- repeat 2+3 until approval is given
- wait for PR to be merged - might not happen since the approver might not be a committer
- timeout → request PR to be merged
- merge or rerequest merge
- if committer finds problem restart process at step 2
For the privileged (those with commit rights), currently steps 1+7 (create PR + merge) can be executed without a problem (unless I’m mistaken), which isn’t great either imo.
This process could be improved with:
- code owners of every file
- merge rights with file granularity (github might not support this, so an action might have to be written)
Probably there are 2 things that speak against this proposal:
- lack of github features (granular rights)
- people are fine with how things are right now
Both of which are fine and if things stay the way they are, then I’ll just follow it without becoming a maintainer. I’m not the most active member anyway
3 Likes
I agree the process is rocky and could be better for all involved, but I guess–as a maintainer of several packages who does not have and doesn’t really want/need the commit bit–I’m a little skeptical about the value nixpkgs would get out of making all maintainers committers.
Ideally, committers have a fairly good idea of what they’re doing at the nixpkgs level. They probably understand the processes for staging/staging-next, backports, and so on. They hopefully understand what Nix features and language patterns are prohibited and/or discouraged in nixpkgs.
I don’t need to understand nixpkgs-level concerns in order to maintain a small number of packages. It is easier to maintain packages when I can leave higher-level concerns to people who have built up their understanding of nixpkgs from a broad pattern of regular contributions over months or years.
It already makes me uncomfortable to see committers merging their own PRs, but policing that isn’t my job. If we agree (and I imagine we do at least abstractly) that a maintainer-committer shouldn’t be merging their own PRs anyways, they’ll still need another committer.
If you’re proposing giving maintainer-committers a lever that would enable them to merge their own PR, I’d only (personally) agree if it was still signed off on by people with the kind of systemic nixpkgs knowledge that the commit bit usually reflects. Adding a bunch of less-knowledgable maintainer-committers to the class of committers seems to require some new designation to indicate who is trusted to give final sign-off from a systemic perspective.
(I personally imagine quality would devolve if the lever could be pulled after approval by another maintainer-committer who hadn’t demonstrated that ongoing commitment and hopefully accrued the expected knowledge. If we were only willing to grant maintainer-committer status to people who demonstrated this commitment and knowledge, we’d have a lot more unmaintained packages.)
Edit: wanted to more directly address the metaphor:
If I had to maintain cars, servers, plumbing, wiring, or what have you, for a living, I would require the ability to execute
Your changes have the ability to break or disrupt the functioning of an entire system–the whole repository. Nixpkgs committers are people who maintain nixpkgs–not individual packages. People who want to maintain a package with greater degrees of freedom can publish a flake or look into GitHub - nix-community/NUR: Nix User Repository: User contributed nix packages [maintainer=@Mic92].
2 Likes
Perhaps a way to address the coarse-granularity issue would be to introduce a lieutenant repo system similar to what the Linux kernel project does.
Currently, all Nixpkgs PRs are submitted to NixOS/nixpkgs, with a few people having committed rights but without clear responsibilities on who exactly should take care of reviewing and merging them. In contrast, the lieutenant model would have several repositories to submit PRs to. These “lieutenant” repositories could be divided by e.g. package category or language framework. The maintainers of these repos then review and merge the PRs on their repos and then collect them in batches for submission to the main Nixpkgs repo. This way, the volume of PRs per repo could be kept reasonably low so that the maintainer of a single lieutenant repo could still take responsibility for every single PR submitted to their repo. Also, the risk of giving a maintainer commit access to a lieutenant repo would be not as high as with the current system, as their batch PRs would be independently reviewed by the main committers.
Another advantage of this system is that it could (probably) be concurrently implemented with the current one.
1 Like
One big difference between the kernel and nixpkgs is that the kernel is not regularly renaming variables or changing how the functions behind them work introducing the need for treewide changes which when not done block the CI.
Package categories are rather arbitrary and most packages could easily be in multiple ones. Language frameworks only would make for the core parts of those languages sense but for any consuming tool it does not really but they still sometimes require changes done by the core parts. Due to that and that most languages are spread over multiple directories we would still require the entire repo instead of just a directory. Not that ideal but could still work.
to then get a flood of review comments because complex topics like splicing and cross are not done right.
This would work for some parts that have a low PR volume but for some eg python this wouldn’t work that well I imagine.
3 Likes
I’m not sure this part is true? I read about huge refactors on LWN all the time. Memory folios are one recent big treewide change. But they don’t tend to do things in single big bang commits. They’ll add an interface, convert everything over to it, and then remove the old one, so it takes a while and requires a lot of coordination.
3 Likes
I don’t think it’s an issue, but it would be nice to get maintainers feel special, even if it’s a silly badge on the forum. People would like this.
Also don’t think what Nix can do for you, think what you can do for the Nix!
would be nice to get maintainers feel special, even if it’s a silly badge on the forum.
https://github.com/orgs/NixOS/people ?
But yes, some increased visibility would be a very easy way to buy some goodwill.
1 Like
You get a badge on your GitHub profile!
4 Likes
I don’t know. We have lots of old meta.maintainers entries where those people don’t really maintain (anymore), even for years. Just being listed there does nothing good by itself, so I’m not convinced it should come with extra awards.