What's the point of becoming a package maintainer?

[AMZ-X]

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?

[figsoda]

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.

[AndersonTorres]

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).

[UefiPls]

@abathur

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.

@peterhoeg

But is that an issue? Does it have to come with privilege in order to be worth doing?

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:

1. create PR
2. wait for maintainers to respond (if there are any since owners or maintainers cannot always be identified)
3. timeout → request a review on nixos discourse (one has to even know about this option)
4. repeat 2+3 until approval is given
5. wait for PR to be merged - might not happen since the approver might not be a committer
6. timeout → request PR to be merged
7. merge or rerequest merge
8. 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

[abathur]

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 https://github.com/nix-community/NUR.

[alyaeanyx]

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.

[Sandro]

@alyaeanyx

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.

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.

@alyaeanyx

package category or language framework.

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.

@alyaeanyx

merge the PRs on their repos and then collect them in batches for submission to the main Nixpkgs repo.

to then get a flood of review comments because complex topics like splicing and cross are not done right.

@alyaeanyx

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.

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.

[qyliss]

@Sandro

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.

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.

[panaeon]

@peterhoeg

But is that an issue? Does it have to come with privilege in order to be worth doing?

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!

[peterhoeg]

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.

[qyliss]

You get a badge on your GitHub profile!

[vcunat]

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.