Automatic retirement of @edwtjo

[nixpkgs-committers]

This is an automated PR to retire @edwtjo as a Nixpkgs committer because they have not used their commit access in the past year.

@edwtjo: You can make a comment stating why you believe your commit access should be kept. Otherwise, this PR will be merged and implemented in one month.

Note

Commit access is not required for most forms of contributing, including being a maintainer and reviewing PRs. It is only needed for things that require write permissions to Nixpkgs, such as merging PRs.

[edwtjo]

I have been a long time contributor, since 2013, and have open PRs and commitment within nixpkgs nor is it my intention to leave or to never again review PRs. I have access to specialized hardware which has required me to merge my own PRs, like the nvidia datacenter (NixOS/nixpkgs@9b95f21) drivers. I also believe that the long time commitment should count for something in terms of trustworthiness and reliability, even if my contributions are sporadic.

[wolfgangwalther]

This is one of the cases mentioned in #73 (comment), where the retirement script does not count squash and rebase merges from ~ the first half of the year. There were 3 of these in December and January, so the script would have created the PR in January anyway.

I have been a long time contributor, since 2013, and have open PRs and commitment within nixpkgs nor is it my intention to leave or to never again review PRs.

Thanks for the feedback!

I have access to specialized hardware which has required me to merge my own PRs, like the nvidia datacenter (NixOS/nixpkgs@9b95f21) drivers.

Ah, I had already written up a question about the self-merges, before your edit, thanks for clarifying that. While they are not strictly forbidden, it's also not really the model we'd like to operate on in principle. Does the special hardware situation affect only a few specific packages or do they effectively require changes across the tree? I'm also not fully convinced why special hardware requires the commit bit - it's clear that only you could test these things, yes, but why would that stop somebody else from merging your PRs?

I also believe that the long time commitment should count for something in terms of trustworthiness and reliability, even if my contributions are sporadic.

When the commit bit is removed, you will be added to the Retired Nixpkgs Contributors team, which will make it easy for you to get back the commit bit once you need it. You can find more background about why we're removing inactive committers in RFC 55. TLDR: This is not about trustworthiness or reliability - these are not questioned at all. This is just about "privileges should only be handed out while required", so just about using them or not.

[edwtjo]

I appreciate that the behavior isn't ideal, and praxis in nixpkgs has evolved over time sure. In my head it is the case that whoever merges the PR should vouch for it actually working. This would result in a sort of fake confidence, where the committer is just blindly taking action, or worse, stalling the process without any qualitative reason, since they are unable to test the changes.

[edwtjo]

On another note I see this in RFC55:

That year is measured from January 1 to December 31 instead of using a rolling window over the last 12 months, to be more predictable for committers and reduce the evaluations from 12 times a year to just once a year.

And to my knowledge December 31 hasn't occured yet, so there is still time for me to show I'm not inactive :)

Does the special hardware situation affect only a few specific packages or do they effectively require changes across the tree?

I would say a small number of packages and nixos modules.

[wolfgangwalther]

And to my knowledge December 31 hasn't occured yet, so there is still time for me to show I'm not inactive :)

Right, that has evolved from the RFC - we are always looking at a moving window of "one year from now". That means you have even longer, until January 28. The reason this PR comes up now is just because of some change in automation, as mentioned in my message initially. So we certainly don't need to act on it immediately, no worries.

[emilazy]

I appreciate that the behavior isn't ideal, and praxis in nixpkgs has evolved over time sure. In my head it is the case that whoever merges the PR should vouch for it actually working. This would result in a sort of fake confidence, where the committer is just blindly taking action, or worse, stalling the process without any qualitative reason, since they are unable to test the changes.

FWIW, although we don’t have a strict rule against self‐merges and they’re necessary in some cases (e.g. regular time‐critical security updates like for browsers), I think a contribution from someone who has tested it on the relevant hardware being merged by a second person who has taken a look over the change offers more assurance than a self‐merge by the original contributor.

I would agree that people merging pull requests take responsibility for the effects of the merge, but that doesn’t mean they have to do all the testing themselves; I think it’s perfectly fine for people to do code review to ensure the contribution looks sound, but defer extensive testing to contributors with the appropriate setup for it – there’s always some degree of trust involved when dealing with contributions for a use case that doesn’t match the merger’s. It wouldn’t be realistic to expect us to have a committer for every piece of hardware we support :)

I agree that is not a great track record, but this leaves out the fact that some packages get auto-updated and merged and doesn't really need review

(Automatic updates do still need someone to check and merge them – and we certainly hope that the relevant package maintainers do it, for the same reasons that we’d prefer PRs in general to be reviewed by people who know the packages and modules being touched, and to ease the triage burden on committers as a whole. That said, the maintainer list entry is a separate matter to the commit bit here, especially as the merge bot means even non‐committer maintainers can merge automatic updates to their packages.)

---

The team took a look at this, due to the discussion here, and since this automatic retirement PR would have been opened in a month even without the API change (the amendment to use a rolling yearly window was approved in #62).

There were two merges at the start of 2025, and four in 2024; all self‐merges. The last merge of anyone else’s PR was in April 2023. Based on this, we would generally be inclined to implement this once it becomes due in the absence of further review and merge activity, per the reasoning in RFC 55.

Your work on support for data centre GPUs is definitely appreciated, and we hope you continue with it! In terms of commit access though, we’d generally need quite a strong reason to defer retirement past the standard period, and would point people to the Discourse thread and Matrix room if they need help getting PRs reviewed and merged, rather than maintaining commit access to all of Nixpkgs if it’s only being used very infrequently and not to merge anyone else’s changes.

[edwtjo]

Ok that is fine, thanks @emilazy! These rules are relatively new and if I interpret #62 correctly, it doesn't say anything about self-merges. This still gives me until January 28th until the window closes, or am I being thick?

At any rate, reviewing others PRs would be something I would be doing if I were to increase my activity. Which I also agree on is a pretty sane prerequisite for commit access. Unfortunately, I only use matrix sporadically of the two messaging platforms. Is participation on Discord required (EDIT: I misread, I'm on the discourse forum)? I actually agree that it is better with general transparent rules without special treatment complicating scripts and what not.

A bit of-topic perhaps; Since this discussion involves frowned upon behaviors, I have some questions. Since I've removed myself from a bunch of packages as maintainer: Is it also frowned upon to merge PRs where you yourself isn't listed as maintainer? Is there some limit on the amount of approvals needed for merging? Does approval matter for r-ryantm updates if checks pass? And how do I find all the rules, is it wading through RFCs? It would be nice if duties/behaviors were kept up to date in one place, like at nixpkgs-committers.

[niklaskorz]

Is participation on Discord required (because I would prefer not to use it)?

Discourse, which is our open source, selfhosted forum, not Discord, the proprietary messaging platform.

Also, you need neither Discourse or Matrix to find PRs needing attention. Next to nixpkgs' PR tab, there also is this helpful tool by @FliegendeWurst: https://nixpkgs-prs.fliegendewurst.eu/ (though I wish it had a filter for last date of activity)

[edwtjo]

Also, you need neither Discourse or Matrix to find PRs needing attention. Next to nixpkgs' PR tab, there also is this helpful tool by @FliegendeWurst: https://nixpkgs-prs.fliegendewurst.eu/

That is very nice, thank you for the tip!

[wolfgangwalther]

Is it also frowned upon to merge PRs where you yourself isn't listed as maintainer?

Certainly not, this is entirely fine. It is expected, even. If you could only merge as a maintainer, the big majority of packages would never be changed at all.

Is there some limit on the amount of approvals needed for merging?

No, there is not. In general, you'll want to have somebody else approve your PR first, before you self-merge. But other than that, once you merge a PR, you are approving it implicitly.

The raw number of approvals also doesn't say much. You'll need to judge what these approvals mean - what did the approver do to verify the PR, what did they test etc.?

Does approval matter for r-ryantm updates if checks pass?

Approvals by themselves don't matter. If you're confident in the change, merge it.

(Your approvals as a committer can matter for packages maintained by non-committers: Under certain conditions, the merge-bot will allow regular maintainers to merge a PR once it was approved by a committer. So it's best to treat your own approvals as "this is ready to merge". If you don't merge immediately, but just approve, that's most likely because you want to give others more time to have a look at the changes, too - but not because "it's mostly fine, but I'm not 100% sure")

And how do I find all the rules, is it wading through RFCs? It would be nice if duties/behaviors were kept up to date in one place, like at nixpkgs-committers.

There is NixOS/org#122, which discusses this. It's an unsolved problem, so far. There is also a comment of mine about my own approach to self-merging in NixOS/org#122 (comment). Philip has written a list of "committer standards" in NixOS/org#122 (comment).

Of course https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md has a lot of things to say about his, especially the sections:

• How to review pull requests: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests
• How to merge pull requests yourself: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-merge-pull-requests-yourself
• Review and Merge conventions: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#review-and-merge-conventions
• And the whole "practical contributing advice": https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#practical-contributing-advice