Nixpkgs: New nixpkgs committers requests

[Infinisil]

This issue is used to nominate people for commit rights instead, scroll to the bottom to see how it's done.

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 #47255), closure size reductions (e.g #49315) and security updates (e.g #49859, #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 [e-mail]
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
https://github.com/NixOS/nixpkgs/issues/50105#issuecomment-437572238,
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 #47407, #49884 and #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.

[aanderse]

Is the team taking names for consideration now? If there is still the desire to find help I wouldn't mind throwing my name into the pool of people interested.

[FRidh]

What I would like to know is what members intend to do, that is, what parts of Nixpkgs do they want to work on, and what do they want to be responsible for. The repository is large, and it's close to impossible for anyone to keep up to speed with everything that's happening inside it. While we can add more people to merge changes, and keep adding more packages, there are various bottlenecks that need to be addressed.

An important part is also, what are our expectations of Nixpkgs? Aside from the stable releases, many users use Nixpkgs as a rolling release. A rolling release requires far more effort to keep a working package set. I'm hijacking the thread here a bit, but simply saying "we need more people to review and merge" is a bit short-sighted. While I would like to have more people involved, I think it's more important that we come up with a strategy for Nixpkgs, and how we deal with Nixpkgs members is going to depend on and be a part of that strategy.

[domenkozar]

I think there are a few issues to tackle here, but they are not so much related.

Nixpkgs has an ever growing number of PR's but not enough people to review and merge them

That's a problem we have to solve. So far, to-be maintainers were nominated on IRC and we agreed upon which to give access. I think the process as such is not perfect, but fixing the stated problem is more about making the process of nomination more explicit, known and transparent. I wouldn't impose any kinds of limits how to gain access (I remember how terrible Gentoo process was with this quizz). I think it's better to leave the judgement to existing contributors rather than come up with some unified scheme of scoring that can be gamed.

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.

It's not random, we so far delegated the judgement to existing commmiters and that worked pretty well.

I think we need:

• a form to submit that will nominate a potential committer
• have a way to discuss the nomination (github teams are pretty cool here since we can limit discussion only to committers)
• have more documentation about what is the responsibility of the commiter and a nice welcoming text

A completely different discussion is changing the structure of the current maintainer flat structure into something more organized.

[7c6f434c]

@domenkozar Re: gaming — well, there is also a value in something to help with the impostor syndrome and to suggest to people when it makes sense to self-nominate.

Better documentation of expectations from committers is also nice, of course.

[edolstra]

Nixpkgs has an ever growing number of PR's but not enough people to review and merge them

The solution to this is to modularize (split) Nixpkgs. For example, most NixOS modules should be maintained in separate repositories (== "flakes"). Then we don't need to have hundreds of direct committers to a huge mono-repository. Of course this will also scale much better in terms of Nixpkgs download time, evaluation speed/memory use, etc.

[oxij]

(read the bottom of the message first)

The solution to this is to modularize (split) Nixpkgs. For example, most NixOS modules should be maintained in separate repositories (== "flakes").

Of all the problems NixOS has, I don't think maintainership of modules is an issue. IMHO, the main issues are:

• general "unwillingness" to test NixOS changes by the community, some fairly simple changes sometimes take years to merge because nobody is willing merge them untested, but accumulating a critical mass of testing requires years without merging to master where most people will see them

  (IMHO, this can only get worse with "flakes", as now you would have to follow and harmonize several distinct repositories to make some high-level feature work.)

• I think the "unwillingness" at least in part stems from poor discoverability of PRs on GitHub, i.e. "How do I find NixOS PRs in a mergeable state that might interest me?"

  (IMHO, again, this can only get worse with "flakes".)
  (IMHO, Nixpkgs is just too big for GitHub.)

• a particularly important case of discoverability is a mention bot or a similar system that should allow linking between related PRs. Clearly, the most likely parties to be interested in the change are those who made related changes before. It seems strange to me that nobody except me seems to be particularly frustrated by the lack of a mention bot. I got so frustrated that I actually made a similar/related thing myself and will start using it from the next PR I make, just wait :]

I do agree, however, that modularizing in the Linux sense, i.e. multiple repositories with a common tree, is a good idea. Like, for instance, having all package updates go into a separate GitHub repo would be nice. But GitHub, AFAIK, doesn't support that workflow well (like PR numbers would get all messed up between repos by default unless some conscious effort is given to clearly mark them with correct prefixes).

Also, currently it is very hard to subscribe to "common NixOS infrastructure, not any particular service" based just on options and paths, e.g. some services live in "config", some in "hardware", some in other random places. The option names they define are pretty much random. E.g., consider PulseAudio: it lives in "/nixos/config", defines "hardware.pulseaudio", while clearly implementing a service. Cleaning that up would be good.

An immediately applicable measures that, I think, would improve things for NixOS:

• make a "nixos-next" branch (like "staging-next" that should be called just "next") for "should be good, but needs testing" changes, merge it only when all nixos tests pass,
  (I would build my laptop against it most of the time, I do that against "staging" and "staging-next" from time to time, doCheckByDefault helps with that.)
• cleanup nixos modules so that one could sanely use configure.nix options and (even more importantly) repository paths as filters (e.g. for CODEOWNERS) for nixos.

[veprbl]

I don't think NixOS has any shortage of people with commit bits. NixOS organisation has 65 members, plus, the nixpkgs repository has some additional committers that are not members. Looking at the list of members, I don't recall ~half of the names to ever merge a PR I looked at. Out of the remaining "half", a ~half would be mostly working on infrastructure and/or mostly merge their own PR or commit directly (I don't say they are not doing an important job, but in this issue we talk about reviewing PR's). My point is that putting work into reviewing those piles of PR's is not a small endeavour. In my opinion, the people who are willing to do that for free should be valued at a price of gold in the community. It will not be easy to find more people to help with that kind of work. I believe that just increasing number of people with commit privilege is unlikely to help the situation - it was not so effective before and I don't see any indication that it will help in the future. A more effective solution might have to do with improving the nixpkgs infrastructure to improve efficiency and convenience for people who are willing to work on reviewing. I don't know what exactly needs to be done. It could be improving some CI capabilities of @GrahamcOfBorg or adding functionality similar to Rust community's @bors or perhaps even gamifying the process a little bit (e.g. @rust-highfive).

[Infinisil]

@veprbl The thing is, people might get commit access at some point because they have a lot of time and motivation to contribute, and that is a great help at that time. But times change, people change, they might get inactive or change their field. Those are the inactive people with commit access, most of them contributed well at some point.

We also discussed this a bit on IRC on how to fix this: People no longer active in the Nix community should be taken away commit rights after some amount of inactivity. Specifically, after 1 year of not participating in any nixpkgs issues/PRs this could happen, people seemed to agree on this.

[veprbl]

@Infinisil The number of members doesn't bother me at all and I'm not calling for purges of any kind. That was not my point. I'm just skeptical about your proposed extensive solution to increase the number of maintainers to solve the problem of PR pileup. I think there are some unexplored intensive measures that we could take.

[Infinisil]

@veprbl Well I'm certainly up for some purging though! I understand what you mean, but I disagree. Let's look at it like this:

• We have a certain number of people with commit rights
• Over time, some of these people become inactive
• This means, over time we have less and less active committers
• In order to prevent this, we need to add more new active committers than current committers become inactive
• Who can become an active committer? Active nixpkgs people, what this issue is about
• How can they become a committer? By knowing how to get commit rights, what this issue is also about

I think these 2 questions have long been standing in the way of many people trying to think of becoming an active committer. People don't know what "active" means and whether they are eligible. And people don't know how to ask for commit rights.

How did I get commit rights? After asking around a lot on IRC, I got the answer that I should ask @edolstra directly. So I asked him directly in IRC, and he was kind enough to give me these rights. Yes it worked, but it took me way too long to figure this out, and not everybody can figure this out, it's written down nowhere.

And yes, as seen in this issue, there are people who want commit rights, I don't think we'll have trouble finding them. On top of my mind, I know that both @worldofpeace and @kalbasit are relatively new community members both helping out a lot (thanks!) and wishing to get commit rights to be able to help out even more, and I'm sure there's more people to come in the future, this project is growing a lot after all!

I think this issue should stay a place to discuss how we can make the process of getting new committers easier and more standardized, not whether we should. We need to get new committers, there's no way around it, and this project wouldn't be this far if we didn't add new committers in the past. As a datapoint, @edolstra made me a committer 4 months ago and I merged 236 pull requests since then. I couldn't have helped out this much if I weren't a committer.

[7c6f434c]

Re: splitting the repository: I remember NixOS being in a separate repository. But then some changes needed to be applied to both repos in sync, which lead to eventual migration of NixOS into Nixpkgs repository. I would expect spinning out overlays out of Nixpkgs to cause similar problems.

[alyssais]

One of the things that has made Nix appealing to me (and easy to contribute to) so far for me has been that everything lives in one big repository. It means that there is one single directory I can grep through when I'm trying to figure out how something works, and one repository that I can bisect really easily when something has broken. Any time I've tried to figure out how something works on any other free operating system, I've become lost in a sea of repositories, where there's no way to reconcile which revisions match up, and to figure out what was used to build a system. For me, the monorepo has been one of NixOS's biggest strengths.

On the topic of new contributors, from my perspective as somebody who hopes to (at some point) become a Nixpkgs committer, and who has previously been one for another large package manager (Homebrew):

• "To have review at least 20 non-trivial PR's" – as a non-committer to a free software project, it's often not clear to me whether reviews from non-committers are welcome. It can feel like there's not really any reason for my feedback to be needed, because it's not going to be up to me to decide whether to merge. Maybe I'm just going to be annoying people and getting in the way.

  I've been around Nixpkgs enough to know that, in this community, that's not the case, but in general, when coming to a new project I might like to some day be a part of, that's not clear to me. And if that's part of the path to becoming a committer, it should be stated that this type of feedback from non-committers is welcomed, so that people don't miss out on that by not realising it.

• I would be wary of over-formalising. If you have an entirely numeric public set of benchmarks for when somebody can become (or be considered to become) a contributor, it would be very easy to end up with a situation where there's somebody that the team feels, for whatever reason, wouldn't be a good fit, but has met the benchmarks, and feels that they aren't getting something that they have earned and deserve. On the other hand, those same benchmarks might slow down the process of bringing somebody on board who would unquestionably be an asset. For example, somebody who had made 300 perfect package update PRs and reviewed 300 more from other people would likely be very valuable, even if they had no interest in larger changes or NixOS modules or whatever.

• When people do get commit access, it would be nice for the community to know a little bit about them. I think it would help build the human connection between everybody working on this software, and would be a really nice welcome for the new person. Maybe a "welcome X to nixpkgs" post on Discourse with a little bit about what work they'd been doing and why the rest of the team decided to offer the commit access.

I think there's a middle ground between hard rules and giving commit access to random people. In my mind, I see a flow where maybe 1 reviewer notices a person who has been doing a lot of good work, writes up a private post to the other committers about whether it would be a good idea to bring them on board, and then invites them in if there were no real objections after a certain amount of time would be a perfectly healthy way to grow the community that wouldn't be vulnerable to getting caught up in bureaucracy.

[alyssais]

One more thing: if commit rights were something that had to be requested, I think that might put people off. "What if I'm rejected?", "What if it's rude to ask, and I should wait until I'm invited?". People can be shy or nervous, and it's important to remember that there is a power imbalance here between the "applicant" and the existing committers that could make asking straight up feel daunting.

I think it would be reasonable to assume that anybody with a sustained pattern of contributions would be at least interested in commit rights, and should be offered them when the team thinks it's appropriate. They can always decline. But that way, it's not up to one non-committer to work up the courage to ask.

[7c6f434c]

• "To have review at least 20 non-trivial PR's" – as a non-committer to a free software project, it's often not clear to me whether reviews from non-committers are welcome.

I think right now we don't make it clear enough they are. I think a public document that says we expect new committers to have already reviewed PRs would be a part of making it clear. I have also expressed my doubt about the balance of numbers.

• I would be wary of over-formalising. If you have an entirely numeric public set of benchmarks for when somebody can become (or be considered to become) a contributor, it would be very easy to end up with a situation where there's somebody that the team feels, for whatever reason, wouldn't be a good fit, but has met the benchmarks, and feels that they aren't getting something that they have earned and deserve. On the other hand, those same benchmarks might slow down the process of bringing somebody on board who would unquestionably be an asset.

I do hope that people who are much better than me in writing texts for humans will succeed in positioning guidelines in a proper way. These should eventually be «typical expected experience level around the time of receiving commit access» or something like that.

I do not expect any problems with positive exceptions, although these will probably still take more time than the streamlined main process.

Negative exceptions are harder, of course; in some sense, I expect them to be predictable early in advance (probably before 20 accepted PRs), but no idea what is the best way to handle this proactively.

• When people do get commit access, it would be nice for the community to know a little bit about them. I think it would help build the human connection between everybody working on this software, and would be a really nice welcome for the new person. Maybe a "welcome X to nixpkgs" post on Discourse with a little bit about what work they'd been doing and why the rest of the team decided to offer the commit access.

I feel «welcome X to Nixpkgs» has unfortunate implications about non-committers, more like «welcome X to Nixpkgs committers».

I have an expectation that «why the rest of team has decided» might encourage writing some paragraph in exact same words in almost every post like that.

I think regardless of human connection, knowing who is interested in what technical areas is very useful, and we seem to be beyond the point of being able to keep track of that without technical aids.

I think it would be reasonable to assume that anybody with a sustained pattern of contributions would be at least interested in commit rights, and should be offered them when the team thinks it's appropriate. They can always decline. But that way, it's not up to one non-committer to work up the courage to ask.

On the other hand, if we want the process not to be blocked on the community-focused people in the team having or not having enough time, we need to make sure that asking for commit access is a normal thing that people do (and succeed). I hope guidelines will help with impostor syndrome (if you meet the guidelines, yes you do have enough experience and no nobody can keep track of everything in Nixpkgs anyway). But quietly doing useful work in the neglected corners makes a person harder to notice — and at the same time, it makes the same person valuable in an irreplaceable way.

And people who apply might have an easier time to remember some examples of their less straitforward contributions. Trying to quickly review contributions of many people to find out who has been missed is tiring (I know, I have tried to do that systematically but gave up after doing it a few times and talking a few people into succesfully applying). Keeping notes between the attempts could be helpful, I guess, but then we might end up with a leaderboard for a race towards commit access… Maybe at least a non-public one.

Or maybe joining this with the «interested in …» list could lead to a wiki about community members with areas of current interest and links to recent examples of things people participated in; that could help with both finding people to ask for advice/review, and with looking for people missed by commit access offers.

Basically, every process that requires regular active involvement from existing committers has a risk of stalling, and if we make the default to be «offering the access», people who are missed might think they just need to wait.

[makefu]

I am very much in favor of an approval system + automatic merge by ofBorg because i personally do not want to have direct commit access to nixpkgs master but i actually do like to help out with PRs by performing reviews. For me pushing directly to the branches of the repo is a super scary thought and having some automatic entity which actually performs the merge gives an ease of mind.

Right now what i am doing is occasionally is reviewing changes and use the approve functionality by github to mark PRs as "lgtm". This makes it easier for certain maintainers i know personally (e.g. @Mic92 ) to actually perform a quick check and merge.

[kalbasit]

For me pushing directly to the branches of the repo is a super scary thought

Personally, I disabled pushing to origin with git remote set-url --push origin no_push that way I cannot make a mistake and push to the wrong fork.

[Infinisil]

Here's a simple idea which could slow down our current incoming PR rate by a lot:

Add a section like the following to the start of the PR template (in a comment):

Currently nixpkgs has a lot of new incoming PR's but not enough people to review this constant stream. Even if you aren't a committer, we would appreciate a review fro you, even for a simple package update. If you have certain packages you are familiar with, search for PR's relevant to them. Check out https://github.com/NixOS/nixpkgs/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+-label%3A%222.status%3A+work-in-progress%22+ to see ready open PR's. See https://nixos.org/nixpkgs/manual/#sec-reviewing-contributions for details on what to pay attention to when reviewing.
Reviewing PR's isn't mandatory of course, but it would help out the committers immensely and make the time-to-merge shorter for all of us. And if you have some experience with reviewing, feel confident and want to help out even more, feel free to ask for becoming a committer in #50105!

[periklis]

Let me jump on this train starting with a little bit of background about my activities on nixpkgs. I've been using nixpkgs on a darwin since 2015 and switched to a full NixOS 18.09 lately at work only. I've created around 47 PR over time with a variety of concerns. Sometimes just update a package or fix the darwin build and another time introduce packages i regularly use at work. In addition i tried to help part-time by following the cross-compilation efforts of @Ericson2314 and gave feedback from my experiments and still try to help our security team. Furthermore, i try to help new-coming Nix-fellows from my own company when they start with their PRs by applying the following steps:

• Review their PR - even as non-commiter- and give an "LGTM" at the end of the process.
• Test the PR with nix-review and give feedback to the PR-Author on GH.
• Ping the package maintainer from the meta block.
• Keep an eye on the ofborg results if a maintainer shows up and teach people how to interpret failures.

In total i feel very comfortable with not having any commit rights. I feel that as a non-commiter you can help a lot without accessing master/staging/etc. by yourself. This gives you imho the option to step back when other things are more important and this happens a lot in companies where you don't do Nix for a living (hey i've to keep our kubernetes platform running). Being a non-commiter gives you the freedom to support more on the testing and documentation side, which imho is needed more than committing code in the Nix/NixOS ecosystem.

To summarize i would like to see a non-commiter status for people who apply in nixpkgs a set of valuable review steps to help maintainers like the above list (e.g. code review, nix-review, of-borg remarks). I think our maintainers would have an easier time to merge PRs if they can trust non-commiters' review according to a solid policy. In addition this would help non-commiters to know how they can be valuable. Of course an additional mention-bot or so like for these non-commiter-reviewers would be helpful to keep them on the track.

PS: Imho a free software projects lives more with a solid policy of participation on the non-commiter side than by making rules of who can be a maintainer. The maintainer team should have additionally a subjective opinion on who is a good fit and who is not. Sometimes the ultimate committer is just a PITA fellow.

[dasJ]

Commenting here as well as I was sent here form IRC. The website still states please ask Eelco, or on the #nixos IRC channel, but it seems like this issue is the new way to go.
I totally agree with most of the points stated above, but I don't feel like I'm in the position to judge about an application process I didn't even pass yet.

So as I asked @Infinisil on IRC and got sent here, I'll just "apply" here for testing the new workflow once there is one.
In the past, I contributed some module changes and new packages which I maintain now. However, package updates and minor fixes often stall as PRs.
I hope to be able to make this easier for me (as I don't have to wait) and also easier for other committers (as they don't have to merge my stuff).
Also, I hope to be able to merge smaller PRs to reduce the number of open ones.

[FRidh]

I hope to be able to make this easier for me (as I don't have to wait) and also easier for other committers (as they don't have to merge my stuff).

This I don't agree with. We should aim at not merging our own stuff, and instead review/merge others' work.

[7c6f434c]

We should aim at not merging our own stuff

I don't think there is any evidence we are even close to being able to afford thisposition. The number of open PRs keeps creeping up.

[dasJ]

@FRidh Sorry, this might have been a bit unclear. From my current PRs, there are things I would merge if there are no responses within a week or so (#55937), because it's small and fixes stuff. There are also other PRs (maybe #44629), I wouldn't merge myself as it's non-trivial.
I think self-merging isn't something to forbid, but something to set rules to because as @7c6f434c said we're just not a big-enough community to have peer-review for every minor change. Maybe this will work in the future, but not yet. Maybe ofborg can help here identifying trivial changes and allowing automerging for trusted users.

[7c6f434c]

I wouldn't say «not big enough», more like «not stabilised enough as a community, and with too varied interests». Obviously, we have enough people to support a feature scope similar to Triton but with multiple review. Whether enough people are interested in that is another question. If yes — maybe there could be a core with stricter rules and an official overlay with the milder rules. I am not sure that the strict-rules core will be enough even for the current graphical installtion image, but if overlays work fine, it shouldn't be that important.

[Infinisil]

Other idea (probably needs an RFC):

Create a nixpkgs-nominations repository that contains instructions on how to become a nixpkgs committer, which would go something like this (similar to the current RFC process):

• Open a PR that adds a a file committers/<name>.md containing
  
  
  
  • How they have been involved in the Nix community (commenting on PRs/issues? IRC? Discourse? Making package upgrade PRs? ...), optionally also include some links.
  
  
  • What they intend to focus on in nixpkgs (Package upgrades? NixOS modules? Specific package set maintenance? Cross compilation? Documentation? ...)
  
  
• People can upvote their nomination to support them, leave comments to "interview" them or ask for clarification, or downvote with an explanatory comment on why they don't support them.
• A small group of people (probably the ones that can give commit rights) will have the final decision to either accept or reject the PR, based on the nomination and discussion around it
  
  
  
  • In case it gets accepted, the person gets commit rights
  
  
  • In case it gets rejected, the person won't get commit rights for the immediate future. They may try again later if they feel like they are more fit at that time.
  
  

[7c6f434c]

If anyone writes this RFC, please do not forget to include «merging good minor PRs» as one of the suggested aims.

[marsam]

What is the procedure to request commit access?
I'd like to request commit access to help with the PR pileup. I've using nix for about 2 years and have around 160+ commits to nixpkgs.

[domenkozar]

@Infinisil I'd love for that to happen, let not anyone you from doing it :)

Sent invitations to @marsam and @periklis

[7c6f434c]

@Infinisil by the way if it is _nominations_, is it a supported scenario to create a PR with explanation why I want to nominate a contributor (with highlights of their previous great work in the public space)? Of course they can decline.

This is partially in response to the point of @alyssais about some people being too cautious/shy/humble to ask when it makes sense.

[romildo]

Following marsam's request, I would like to have commit access too. According to github, I have contributed up to now with 1008 commits to master, excluding merge commits, and I am ranked 30 in the contributors list.

[domenkozar]

Only if Brazilian humor persists. Joking aside (the correct one), I've sent you an invitation.

[7c6f434c]

@domenkozar I think you missed @aanderse

(which might have something to do with the message worded in a way that escapes most reasonable search requests…)

[domenkozar]

@aanderse any chance you can set your name/surname on github? And ideally an avatar :)

[aanderse]

@aanderse any chance you can set your name/surname on github? And ideally an avatar :)

@domenkozar As requested.

[Profpatsch]

@domenkozar I nominate @Lassulus for commit access.

[domenkozar]

@Profpatsch based on https://github.com/NixOS/nixpkgs/commits?author=Lassulus?

[Profpatsch]

@domenkozar yeah, he’s also the leader of the biggest regular NixOS meetings (at cbase).

[domenkozar]

For some reason github showed me only 5 commits yesterday :) Invited.

PS: I also like dogs that write tests

[Lassulus]

@domenkozar Thanks!
yes, I forgot to add my main mail-address to my github account. Just added it tonight.

PS: Wuff Wuff

[domenkozar]

Also gave access to @teto

[rvolosatovs]

I'd be willing to help too.
https://github.com/NixOS/nixpkgs/commits?author=rvolosatovs

[Infinisil]

It would be nice to see at least these points from everybody that nominates themselves here, as suggested in a previous comment:

• How have you been involved in the Nix community (commenting on PRs/issues? IRC? Discourse? Making package upgrade PRs? ...), optionally also include some links.
• What do you intend to focus on in nixpkgs (Package upgrades? NixOS modules? Specific package set maintenance? Cross compilation? Documentation? ...)

[dasJ]

Info as requested:
I don't have as many contributions yet. I mostly work on PRs (opening, commenting, reviewing). I usually hang around on IRC (bounced) and try to help people when I know some solution.

I intend to perform package updates, add new packages and fix bugs by upstreaming my locally-developed module fixes. I might get into more cross-compilation stuff, as I also run NixOS on my Pi, maybe there is some future for me here.

[rvolosatovs]

Regarding https://github.com/NixOS/nixpkgs/issues/50105#issuecomment-486686762:

• I'm mostly involved in Nix community via opening PRs. For the most part those are updates or new package additions. I'm not active on either IRC or Discourse(which can change, if necessary)
  You can see my PRs here: https://github.com/NixOS/nixpkgs/pulls?utf8=%E2%9C%93&q=author%3Arvolosatovs+

• Anything Go and (Neo-)Vim related. I'll keep updating things and intend to finally promote my custom ad-hoc NixOS modules to "proper" modules and contribute upstream(https://github.com/rvolosatovs/infrastructure/issues/2). I'm also in progress of setting up a Darwin machine, so making Nix work on Darwin is another goal of mine.

[kalbasit]

Are we still taking nominations? If so, I'd like ti nominate @jonringer for commit access. He's been a very helpful member of our community.

[jonringer]

tbh, I don't trust me :). But I'm still flattered @kalbasit

[kalbasit]

@jonringer makes me trust you even more :-) It looks like you've been added already so congratulations!

[aanderse]

@kalbasit he has added to the maintainers group already, though not the committers group. I strongly endorse @jonringer as well. He has shown the quality of his excellent work through his many reviews and PRs. Definitely an asset for the community.

[worldofpeace]

Indeed, @jonringer has been very helpful. Having commit access could enable him to assist in more direct ways. I've reviewed his code on numerous occasions, he shows a great willingness to respond to the maintainers requests, and seems to keep a good awareness of the code quality we expect in nixpkgs. The sentiment of "tbh, I don't trust me", to me evokes a sense of carefulness. Maintainers should defer to each other, no one's opinion or understanding is absolute. If you feel it's an early decision we'd respect that. But we'd be happy to fill you in on the details / help you along the way if you'd assume the responsibility.

[jonringer]

I'll be happy to take on the responsibility, mostly just afraid of accidentally pushing to master, but I remembered git remote set-url --push origin no_push (thanks @kalbasit) was a thing. :)

Nix resonates with my functional programming side, I'd be very happy to help :)

[jonringer]

@worldofpeace @aanderse @kalbasit I know for ZHF, I alone have 20+ low-threat (1-10 rebuild) PRs that could use some review/merging and I'm sure others have many outstanding PRs open. Is the opportunity for me to help still open?

[teto]

@jonringer has been very helpful fixing packages here and there, reviewing other PRs. I don't know if he checks all the boxes (especially about big PRs) https://github.com/NixOS/nixpkgs/issues/50105#issuecomment-437551200 but I don't think that should be a problem.
Also it would be nice to have a nixos zealot inside microsoft, and, who knows, take over the world ?!

[jonringer]

unfortunately a lot of peers still develop on windows :(. It's ironic though, since most of the new cloud-services we develop usually target a linux workflow (kubernetes/docker)

[marsam]

@domenkozar I would also like to recommend @jonringer, Jon has been really helpful testing and fixing packages.

[7c6f434c]

I am way less active recently, and I still have learned to recognise @jonringer as someone who consistently contributes.

Re: developing on Windows — finding a way to have a native Windows Nix port might also be a useful step to world takeover.

[worldofpeace]

I've asked in #nixos-dev, I've established that I think this is a good idea.
@jonringer I hope to see this granted :sparkle:

[domenkozar]

Sorry @jonringer for so late response, hope I've not discouraged you :) You should have an invite.

[jonringer]

I suddenly noticed I have commit access, :). Glad to be aboard :D

[domenkozar]

Sometimes I get lost because of github spam, don't hesitate to ping me on IRC or other channel.

[jonringer]

I completely understand, I slip on follow-ups from stuff I say I'll do on PRs and never find time to address them.

[domenkozar]

Yes, although this issue is about our community, our people.

I'll bring up this discussion at nixconf, this is not sustainable and we're potentially losing contributors at basics :)

[peti]

I would like to nominate @cdepillabout for Nixpkgs commit access. In the last couple of weeks Dennis has been very active reviewing, testing, and improving dozens of Haskell-related PRs and his contributions have improved the state of the package set a lot. Currently, he basically reviews everything and gets the PR into shape and then tells me to merge it. I would like him to be able to hit that merge button himself without having to wait for me. :-)

[aanderse]

@cdepillabout is solid so a big :+1: on that.

[jonringer]

@cdepillabout I also concur :)

[cdepillabout]

@peti Thanks for the nomination! I'd be glad to use the commit access to continue to help out with Haskell-related PRs and issues.

[edolstra]

@cdepillabout I've sent you an invite for the nixpkgs repo.

[aanderse]

@JohnAZoidberg is someone who has displayed ample aptitude, a discerning eye for PR review, and commitment to the project. I ask that @domenkozar or @edolstra consider offering @JohnAZoidberg an invite for the nixpkgs repo, and that anyone who feels the same way to speak up here.

[domenkozar]

[JohnAZoidberg]

Haha, thank you! :D

Should we maybe move these requests and nominations to Discourse and use this thread for actual discussion about the requirements and process?

[domenkozar]

I'd prefer the other way around, let this be the audit log (as it stands) and discourse for discussion.

[alyssais]

I’d like to nominate @petabyteboy, from whom I have seen good reviews and a very solid understanding of Nixpkgs (especially in #60788). I also think that being a committer would make them better equipped to take on more ambitious projects like the Mastodon one I linked, which failed, AFAICT, due to lack of any sign from committers that anyone would ever end up merging it. This is something that we should work to improve for non-committers, for sure, but I think petabyteboy has demonstrated in that that they have some serious skills to offer, and I think it would be a shame to miss out on them.

[aanderse]

I always find @petabyteboy to do great work in nixpkgs and echo the comments @alyssais has made :+1:

[worldofpeace]

Same, it would be great to have you @petabyteboy

[domenkozar]

Invited since we share the vision - petabytes in cache until retirement.

[aanderse]

It recently came to my attention that @rnhmjoj isn't a committer :open_mouth:. Given their skill, the value of contributions, and commitment to the project I would like to nominate them.

[worldofpeace]

@aanderse What?? I actually assumed they were when I first started contributing.

:+1:

[worldofpeace]

And I'm saying, look at this PR https://github.com/NixOS/nixpkgs/pull/77347. It's really a beauty of packaging and documentation there.

[rnhmjoj]

Sorry I didn't reply earlier, I was busy fixing some nasty problems.
So, thank you for the nomination: it means a lot to me. I would be happy to accept even if I'm pretty afraid of commiting directly: over the years it's become clear that a second set of eyes is almost always needed. Anyway this would be pretty helpful to speed up the process of reviewing other PRs and small changes.

[samueldr]

It's a great sentiment not to want to commit directly. You are still encouraged to use PRs and have other contributors take a look!

[domenkozar]

Invited @rnhmjoj :)

[rnhmjoj]

@domenkozar Thank you! Ahah, I noticed something was off because I received a huge batch of notifications in my inbox. I'll have to lower the watching.

[jonringer]

I would like to nominate @bhipple for committer status. He's been immensely helpful with rust/cargo changes, and I believe he is sincerely committed to the betterment of nix/NixOS/nixpkgs.

He's also been very cooperative with criticism and I think we make a great addition to committers.

cc @ryantm

Edit: linked to wrong issue

[edolstra]

I've invited @bhipple.

[bhipple]

Thank you everyone for the support and vote of confidence, it really means a lot to me!

Like @rnhmjoj I'm a little worried about accidentally pushing garbage straight to master, so I've run git remote set-url --push origin /dev/null in my main development dir as a precaution :sweat_smile:

[JohnAZoidberg]

I'm a little worried about accidentally pushing garbage straight to master

Is master still not a protected branch? If so, what is the reason for allowing directly pushing to master?
I believe no single person should be able to make any (maybe accidental or malicious) changes to nixpkgs without another commiters approval.

I use git remote set-url --push origin [email protected]:JohnAZoidberg/nixpkgs.git to protect nixpkgs and for extra convenience.

[Mic92]

I'm a little worried about accidentally pushing garbage straight to master

Is master still not a protected branch? If so, what is the reason for allowing directly pushing to master?
I believe no single person should be able to make any (maybe accidental or malicious) changes to nixpkgs without another commiters approval.

I use git remote set-url --push origin [email protected]:JohnAZoidberg/nixpkgs.git to protect nixpkgs and for extra convenience.

Documentation backports maybe? Open a pull request for that seems a bit of an overkill in that case.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/branch-protection-policies/6410/1

[7c6f434c]

Is master still not a protected branch? If so, what is the reason for allowing directly pushing to master?
I believe no single person should be able to make any (maybe accidental or malicious) changes to nixpkgs without another commiters approval.

Self-merging limited-impact PRs by maintainers will continue until all non-committer PRs get swift attention (note that with the current PR flow asking a review for committer PRs will not actually lead to the code being read carefully)

I use git remote set-url --push origin [email protected]:JohnAZoidberg/nixpkgs.git to protect nixpkgs and for extra convenience.

I agree that origin remote should typically be a fork and not mainline, I am a bit surprised it is not the majority configuration!

[tfc]

Hello!

In the meantime i have put considerable effort into porting the NixOS integration test driver to python. I also ported many many integration tests to use the new python driver and would consider myself a maintainer of this.

Can i get commit rights in order to be able to merge pull requests that affect this part of the nixpkgs ecosystem? (I would not use this to commit directly without PRs.)

[domenkozar]

Invited :)

@jonringer @bhipple sorry for missing your call, seems like I missed the email.

[timokau]

I would like to nominate @doronbehar. He's been doing a lot of good work on nixpkgs, starting in June 2019. He is not only contributing, but also actively reviewing other people's contributions. Unfortunately a lot of those reviews are not acted upon quickly enough. I think he would be a very valuable addition to nixpkgs-committers.

[veprbl]

I would like to also nominate @risicle . They are an active contributor and seem to be very organized in their work. I believe, they would be a great addition to the team.

• risicle's reviews
• risicle's own PR's

[etu]

I would like to nominate @talyz. He's been doing a lot of great work on nixpkgs since July 2018.

• Talyz's own PR's: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+author%3Atalyz
• Talyz's reviews: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+reviewed-by%3Atalyz+-author%3Atalyz

He's been active related to the Gitlab modules and done lots of good work and more recently @talyz teamed up with me to refactor the PHP ecosystem in Nix and proved there to be of invaluable help: https://github.com/NixOS/nixpkgs/pull/83896

[aanderse]

Every time I interact with @talyz or see the work they do I'm always happy. I support @etu in this proposal :+1:

[globin]

I would like to nominate @elseym. He's been doing work on nixpkgs since October 2017.
Disclaimer: works on the same team as me at mayflower.

• elseym's own PR's: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+author%3Aelseym
• elseym's reviews: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+reviewed-by%3Aelseym+-author%3Aelseym

[domenkozar]

@doronbehar I've gotten private feedback that you're doing good work, but approve PRs prematurely (without testing).

I'd propose you get ofborg access (no idea how that's done) first to be able to build/test things first and then commit access once your workflow improves :)

[domenkozar]

Invited @risicle @elseym @talyz

[domenkozar]

@doronbehar I felt like there's more to be said, I was pretty vague.

First of all I'd like to thank you for all your contributions! I really like to see contributions mainly from those that are not completely familiar and like to get their hands dirty.

I wouldn't like for my response to be a discouragement or a critique, but an invitation for more learning :)

I would also like to apologize in name of the community as we don't have written down all the guidelines we are trying to follow and some we're just figuring out.

You can make a PR to add yourself to https://github.com/NixOS/ofborg/blob/released/config.public.json#L15 and then you can use @GrahamcOfBorg build attribute to test PRs on nixpkgs.

Have fun!

[mmahut]

I would like to nominate @filalex77, he has been doing a great job contributing in the last months and it's always great to work with him.

• Pull requests
• Reviews

[domenkozar]

Invited @filalex77

[NickHu]

Hi, I'd like to request commit access. I've been using nixos solely and contributing for 3 years now, and I feel like I have a good understanding of the general nixpkgs ecosystem.

My commits are here and reviews are here.

I have also contributed to home-manager here.

I've decided that I want to do more to help nixpkgs, so yesterday I asked for some advice on IRC and @cole-h told me that I should try to do more reviews, which I'm now trying to focus on, but I'd also appreciate more feedback from the wider NixOS community at large, thanks!

[domenkozar]

Invited @NickHu :)

[marsam]

I’d like to nominate @zowoq for commit access. They are an active contributor
and immensely helpful member of our community.

• zowoq PRs: https://github.com/NixOS/nixpkgs/pulls/zowoq
• zowoq reviews: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+reviewed-by%3Azowoq

[aanderse]

@danieldk has been around the community for some time now showing motivation and commitment to improving the nix ecosystem. Given their work through various PRs, issues, and discussion on discourse I would suggest they are an ideal candidate for commit access. @danieldk would you be interested in commit access? If so I would like to nominate you.

[danieldk]

@danieldk would you be interested in commit access? If so I would like to nominate you.

I love the Nix ecosystem and contributing to it has been a lot of fun! (Thanks for all the reviews and insightful comments everyone!)

I would definitely like to help out in any way I can. Thanks @aanderse for offering to nominate me, I would be happy and honored to accept.

[balsoft]

Hi, I would like to request commit access. I have been around Nix ecosystem for quite some time (at least 3 years) and have commited to various projects:

• Nix
  
  
  
  • Waiting for build users
  
  
• nixpkgs
  
  
  
  • Static building of OCaml packages
  
  
  • Various other things
  
  
• haskell.nix
• Created opam-nix

I have also been helping other people get a hang of Nix and NixOS on various resources, including https://reddit.com/r/NixOS, https://t.me/ru_nixos, https://matrix.to/#/#nix:matrix.org and lately on IRC.

[jollheef]

@balsoft is one of the most active members of the Russian NixOS community, so I would like to support his nomination.

[domenkozar]

Invited @balsoft @danieldk @zowoq.

[erictapen]

I'd also like to apply for the commit bit.

In the past three and a half years I used, contributed and eventually learned to love NixOS and its community. In that time I aggregated over 90 PRs which resulted in 74 non-merge commits on current master.

In that time I saw quite a few places in the NixOS ecosystem, which are

• Haskell infrastructure
• Nixpkgs documentation system
• Rust build infrastructure
• Cross compilation
• Patching of security issues
• NixOS tests
• Networking (script backend)
• Nix flakes

Some of you may know me from events like CCC, SHA2017 or CCCamp, where I regularly visit the NixOS assembly. I spend a lot of time following discussions on GitHub and Discourse, so I think I have somewhat of an broader overview regarding topics, discussions and traditions in the community.

[cdepillabout]

I'd like to nominate @maralorn for the commit bit.

He's been helping out with the Haskell infrastructure over the past few weeks, and has started contributing (as well as reviewing) a bunch of non-trivial Haskell-related PRs.

We're hoping that he will continue helping us out clean up (and document) the Haskell infrastructure here in nixpkgs.

[maralorn]

Thank you for the nomination @cdepillabout .

I would be very glad to do my part.

[Mic92]

I would like to nominate @mweinelt as a Nixpkgs maintainer:

• @mweinelt PRs: https://github.com/NixOS/nixpkgs/pulls/mweinelt

• @mweinelt reviews: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+reviewed-by%3Amweinelt

• Further references: @andir and @flokli

[flokli]

I'd like to nominate @NinjaTrappeur as a nixpkgs maintainer.

He's been doing quite some good work in various low-level components, such as systemd, the networking subsystem and linux itself.

[mweinelt]

Thanks for the nomination. I'm most interested in network, home-automation and security (for example CVE fixes) and would be happy to contribute in this manner.

[domenkozar]

Invited @mweinelt @NinjaTrappeur @maralorn @erictapen

[cdepillabout]

@maralorn (and any of the other new commiters), you may be interested in adding yourself to the https://github.com/NixOS/nixpkgs/blob/master/.github/CODEOWNERS file. If you add yourself to a path in this file, you will get GitHub notifications (code review requests) for any PR that touches a file in that path.

For example, I've added myself to all the Haskell-related paths, so I get a GitHub notification whenever there is a new PR touching any Haskell-related file:

https://github.com/NixOS/nixpkgs/blob/3c14632da2111cf31ebd49057cd23780c41017fa/.github/CODEOWNERS#L72-L77

This is certainly not required, but it is a helpful mechanism if there is one specific part of nixpkgs you want to focus on.

[aanderse]

As a community we would be lucky to have @stigtsp join the list of committers. The work they have done to build up and maintain our perl infrastructure has been excellent. While perl may not be the most popular language these days there is a ton of it running out there, and sometimes in some very critical places... so having someone like @stigtsp in our community with a deep understanding of the language and its usage in nixpkgs is invaluable to us.

I would like to nominate @stigtsp as a nixpkgs maintainer.

[Mic92]

I would like to nominate @ajs124 as a Nixpkgs maintainer:

@ajs124 PRs: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+author%3Aajs124

@ajs124 reviews: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+reviewed-by%3Aajs124

Further references: @Lassulus and @andir

[worldofpeace]

I would nominate @mkg20001 as a Nixpkgs committer.
He's very bright and his interest in improving NixOS is incredible.

I just helped him integrate Cinnamon DE into nixpkgs, and IMHO, if that's going to be maintained properly he needs to be able to push his own stuff.

@mkg20001 PRs: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+author%3Amkg20001

@mkg20001 reviews: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+reviewed-by%3Amkg20001

Lastly there's plans to create a distro from NixOS that focuses on being user friendly https://github.com/ssd-solar (think like there's manjaro for arch linux)

[timokau]

I would like to re-nominate @doronbehar. I provided links to his contributions in the last post, and he has not slowed down since. He continues to both contribute code and cut down on our backlog with reviews. I think we would benefit from giving him the permissions to do that more effectively.

[domenkozar]

Invited @stigtsp @ajs124 @mkg20001 and @doronbehar.

[mmahut]

I would like to nominate @prusnak as a nixpkgs committer. Pavol has been doing amazing work for NixOS for almost two years. He has done more than 150 pull requests and did almost 200 reviews. I'm sure the community would benefit greatly from this nomination.

[andir]

I would like to nominate @taku0 he has shown a lot of work and energy maintaining (among other things) Firefox and it would really help having another one with commit access in that group of people.

350+ PRs: https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+sort%3Aupdated-desc+is%3Aclosed+author%3Ataku0

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/trust-model-for-nixpkgs/9450/7

[mkg20001]

I would like to nominate @luc65r for his awesome PRs.

He has been learning how to package with me for a long time now and seems to be ready to write things on his own.

[Ekleog]

I would like to nominate @symphorien for both his PRs and his reviews. He's been contributing for about 4 years now, with 187 PRs and 148 reviews, and I think he's more than worth a commit bit.

[domenkozar]

Invited @symphorien (I'd kindly ask to add your name to the github profile).

For @luc65r I suggest we give it a bit more time with 19 pull requests.

[Mic92]

I would like to nominate @SuperSandro2000. He reviewed many pull requests in a short amount of time and also did a fair bit of PRs.

[jonringer]

I would like to second @Mic92, @SuperSandro2000 has helped greatly with many PR reviews :)

[RaghavSood]

I would like to request commit access

I know I've only been around a few months, and made only ~40 PRs, but I would like to help add on to the amazing work @mmahut and others do for our blockchain packages and modules. I work in the crypto space at an exchange, so will generally be quite on top of changes as they happen.

I'm currently working on an effort to clean up and make our blockchain packages and modules more consistent over in #103890, as well as on ad hoc fixes and package updates (across the entire tree, not just blockchains) as I run into them

[prusnak]

Gentle reminder of https://github.com/NixOS/nixpkgs/issues/50105#issuecomment-696021397 :smile:

I would like to nominate @prusnak as a nixpkgs committer. Pavel has been doing amazing work for NixOS for almost two years. He has done more than 150 pull requests and did almost 200 reviews. I'm sure the community would benefit greatly from this nomination.

[FRidh]

I agree with giving commit access to @prusnak as well as @SuperSandro2000, and also @taku0 if they express interest in it. As @andir mentioned @taku0 has been very helpful with maintaining Firefox and Thunderbird.

[taku0]

I'd like to thank you for nominating me and would love to accept. I'm mainly updating Firefox, Thunderbird, and Flash Player.