[2018-2024] Nixpkgs committer nominations

[infinisil]

See this instead: https://github.com/nixos/nixpkgs-committers?tab=readme-ov-file#nominations

---

Before that it was #50

This issue is used to nominate people for commit rights to Nixpkgs. Use reactions like 👍 or ❤️ to indicate your support of others nominations!

Generally the expectation is to have a well-established PR history already. To see your current stats, you can use @lorenzleutgeb's script to see your merged and reviewed PRs.

Original text

Nixpkgs has an ever growing number of PR's but not enough people to review and merge them. We need more nixpkgs committers! But we can't just select a random bunch of people and give them commit rights. It is a matter of trusting them to keep the codebase clean. People should go through a review process to be able to become a committer. This issue should serve as a place to discuss such a process.

https://github.com/orgs/NixOS/teams/nixpkgs-committers/members

[infinisil]

Having discussed this on IRC a bit, this is an arbitrary set of requirements I came up with:

To become a nixpkgs committer you need:

• To have at least 50 merged PR's, 10 of which non-trivial
• To have review at least 20 non-trivial PR's
• To have added at least 2 new packages, to know how to write nix code and package stuff in nixpkgs
• To have written at least 1 NixOS module

Of course, a manual check will be involved as well, but having such a set of requirements could set a baseline.

[infinisil]

In addition, a series of interview questions could be asked, such as:

• "How does master and staging work, when to use what?"
• "Describe the release process, what do you need to look out for during the release time?"
• "There is a PR that updates libfoo, how could you test this PR?"
• "There is a PR that adds 1000 NixOS options, what are potential problems with this?"
• "A PR breaks backwards compatibility, what influences your decision on what to do?"

[infinisil]

• "When would you commit to master directly, versus going through a PR?"

[7c6f434c]

Having discussed this on IRC a bit, this is an arbitrary set of requirements I came up with: To become a nixpkgs committer you need: - To have at least 50 merged PR's, 10 of which non-trivial

Do you want to add that of last 20 PRs _submitted_ there shouldn't be major concerns about code quality during review? Controversial changes being rejected are OK, though. Maybe 50 is slightly too much, and also maybe we want to have some preference about recency (do we want a track record of at least two months? and do we want at least 20 accepted PRs to be less than one year old?)

- To have review at least 20 non-trivial PR's

I have some vague feeling that this is a risky guideline, maybe we just want to lower the number. Basically, we want non-committers to review things where they are already confident, and some part of a person's project participation time should have gone into getting that confidence. Maybe 20 is a large enough number that it looks like we expect people to be a bit more aggressive about what they review. Not sure (as I said, this is a vague feeling).

- To have added at least 2 new packages, to know how to write nix code and package stuff in nixpkgs

I would say explicitly that a notable refactoring of large packages also counts. If there is a place where we can say that we value cleanups, we should say it. Refactorings are normally reviewed in a stricter way than additions anyway.

- To have written at least 1 NixOS module

Not sure I agree with that — I think having more Nix-on-non-NixOS committers is a good idea. I think just asking people not to touch NixOS modules until they have done some changes via PRs (merged by experienced people) should be OK.

Of course, a manual check will be involved as well, but having such a set of requirements could set a baseline.

I am not sure what would be in the manual check as a separate consideration. Obviously, there are a lot os subjective value calls in the guidelines — non-triviality, reasonableness of reviews, code quality problems in recent commits, etc. Exceptions from the baseline guidelines are another story, of course.

[7c6f434c]

Given how things work now, I am not sure what would be a reasonable way to conduct such an interview.

- "Describe the release process, what do you need to look out for during the release time?"

Do many correct answers start with «there is no fixed release process, but generally…»? Actually, recognition that Nix* is very slow to achieve a consensus on long-term decisions could be a good thing to check…

[andrew-d]

A question I don't have a good answer for: should we somehow split up "people who are keeping things up-to-date" vs. "people who we trust to refactor/make sweeping changes"? I'm very much in the set of people that use NixOS, but don't have any strong feelings on how nixpkgs is laid out, what the future direction is, etc., but am happy to submit bugfixes (e.g NixOS/nixpkgs#47255), closure size reductions (e.g NixOS/nixpkgs#49315) and security updates (e.g NixOS/nixpkgs#49859, NixOS/nixpkgs#49860). I have no immediate interest in doing any refactoring of nixpkgs, but would happily use any additional permissions to continue "just fixing things", like above.

[7c6f434c]

A question I don't have a good answer for: should we somehow split up "people who are keeping things up-to-date" vs. "people who we trust to refactor/make sweeping changes"?

Do we have any project member who hasn't submitted PRs because the changes were indeed global enough to discuss? I doubt that. I think making and following reasonable estimates of desired review levels for each change is what we target.

[andrew-d]

Right, sorry, maybe I’m not being clear here. To be super blunt: y’all should (rightly) not trust me / people in my situation to submit arbitrary PRs, but if you could somehow ensure that the only thing we were doing was updating packages (or other non-controversial/scary changes), maybe it would take some load off the trusted reviewers and let them review things that mattered more? Again: just thinking out loud here, so to speak 🙂

…

On Sat, Nov 10, 2018 at 1:54 AM Michael Raskin ***@***.***> wrote: >A question I don't have a good answer for: should we somehow split up "people who are keeping things up-to-date" vs. "people who we trust to refactor/make sweeping changes"? Do we have any project member who hasn't submitted PRs because the changes were indeed global enough to discuss? I doubt that. I think making and following reasonable estimates of desired review levels for each change is what we target. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABB3hSemV6gEn2gSqOxzMkHc5iTli9Grks5utqJtgaJpZM4YXx1N> .

[FRidh]

but if you could somehow ensure that the only thing we were doing was updating packages (or other non-controversial/scary changes)

https://github.com/kragniz/nixbot

[zarelit]

People with commit access are covering many roles that are more or less evident: they reduce the queue of unmerged PRs but at the same time they ask for or make changes (thus contributing to the overall quality) and most of all they are shaping nixpkgs layout and functionality by boosting or closing some PRs.
@infinisil it looks like those guidelines could be a rule of thumb to what can be called a nixpkgs core team, much like the Nix core team but applied to nixpkgs.
At this point we have some people with commit access and, knowing almost nothing of the project history, I can assume they earned it through trust and reputation so there is a process already but it's slow. So are these guidelines a way to measure contributions and speed up the process?

[7c6f434c]

At this point we have some people with commit access and, knowing almost nothing of the project history, I can assume they earned it through trust and reputation so there is a process already but it's slow. So are these guidelines a way to measure contributions and speed up the process?

I think these guidelines don't differ much from when many people get commit access nowadays. Having a published set of guidelines would hopefully reduce uncertainty (and maybe even reduce selection for willingness to ask out of the blue — which sometimes holds some people out of the committer list without a good reason).

[Thra11]

I don't know how easy it is to set up on github, but one way to allow less experienced people to help out with pull requests would be to create an intermediate tier of contributors who don't yet have full commit access, but have the ability to give a PR their approval. Once a PR has been approved by two or three of these 'semi-trusted contributors', it can be automatically committed by a bot.

[7c6f434c]

Once a PR has been approved by two or three of these 'semi-trusted contributors', it can be automatically committed by a bot.

I think once ofBorg — https://github.com/NixOS/ofBorg/ — gets some auto-merge support, it will be reasonably easy to add a few kinds of advanced access control logic. There are tickets about that…

[kalbasit]

@infinisil thank you for starting this process. I've been wondering for a while what are the requirements for me to gain push access and to be a part of the core team to help out with any refactoring or core decisions.

Over the past couple of months, I've submitted a bit over 50 PRs, some are version updates but many are not trivial (such as NixOS/nixpkgs#47407, NixOS/nixpkgs#49884 and NixOS/nixpkgs#49815 among others).

I'd love to be the guinea pig of this process. @infinisil @domenkozar please let me know if I would qualify for the minimal requirements and I'd be happy to jump with you (and anyone else from the team) on a call or chat.