Automatic retirement of Nixpkgs committers

[infinisil]

To reduce toil and improve security, I'd like to spend some time to automate the retirement of inactive Nixpkgs committers, mostly in line with RFC 55 (and RFC 71). In this issue I'm describing the overall plan to implement this.

To go ahead with the implementation, I need explicit approval from:

• All of the Nixpkgs commit delegators @Mic92, @jtojnar and @NickCao, as this is changing the Nixpkgs committer process.
• The @NixOS/steering committee, because the plan does not implement the approved RFC 55 exactly.

Please 👍 this comment if it sounds good to you, or leave a comment for any concerns.

Plan

Primarily for the commit delegators to approve.

Declarative committers

Create https://github.com/NixOS/nixpkgs-committers to declare the committers and introduce automation to sync its state with the Nixpkgs committers team.

• For now only the commit delegators themselves are expected to create and merge PRs to change the committers, while the process of nominating stays the same. This would become easy to change to a PR workflow in the future.
• Automation must add removed committers to the Retired Nixpkgs Contributors team.

Automatic retirement

Set up automation that runs every month to:

• Check for each committer if they've been using their commit permission in the past 12 months (this is a minor deviation, see below).
• If inactive, open a PR that removes and pings them, mentioning that they have 1 month to make a commit or they lose the bit.
• When the workflow runs the next month, any existing PRs will either be merged or closed automatically based on whether the committer has used their commit access or not.

Deviation and empowerment

Primarily for the SC to approve.

Deviation: Rolling window

The new plan is to have a rolling window over the last 12 months, while RFC 55 specified:

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.

The reasons given are not relevant anymore with this plan:

• More predictable: Automation is very predictable, and all users will be well informed in the same way, with always 1 month to commit again to avoid losing access.
• Reduced evaluations: Computers don't get tired from doing something too often. It's even better to run it more, because then we notice problems quicker.

Furthermore, this is fairer, because e.g. two people whose last commit was on 2023-01-01 and 2023-12-31 respectively aren't scheduled to lose their access at the same time on 2025-01-01 (which is ~2 years and ~1 year later respectively), but rather both after ~1 year.

Empowering the commit delegators for future deviations from RFCs

The commit delegators should get explicit authority to make any other commit delegation changes, even if they conflict previous RFCs, without needing further RFC or SC approval.

[pbsds]

Create https://github.com/NixOS/nixpkgs-committers to declare the committers and introduce automation to sync its state with the Nixpkgs committers team.

Why not increase the scope a smidge and name it https://github.com/NixOS/teams? We could then at a later date expand it to declaratively manage nearly all nixos org teams, not just the nixpkgs committers.

[infinisil]

We can rename it later if we decide to use it for other teams as well :)

Ideally we'd have #40 at some point, but I think that's a bit too ambitious for now.

[fricklerhandwerk]

Why not manage team state in Nixpkgs itself? I won't count "it's not part of the productive code" because then the same would apply to maintainers.nix and in any case one can always project out the productive code into read-only repositories.

[infinisil]

@fricklerhandwerk I can't see what the advantage would be tbh.

But a good reason against is security. Since only the Nixpkgs commit delegators should be allowed to change who's a committer, we'd need to set up restrictions for every other committer, and there's many pitfalls to that¹. Nixpkgs CI is already very convoluted but so far not critical in managing permissions, this would change that. In comparison, it's trivial with a separate repo, because we can give exactly those people access that need it.

Furthermore, while I don't propose changing the nomination process yet, if we want to switch it to a model where we open issues/PRs to request changes, it would be very hard for people to subscribe to committer nominations. Currently this is possible by subscribing to the nomination issue, while with a separate repo it's possible by watching the repository.

And intuitively, managing access to something within that very thing sounds just like a bad idea when we have alternatives :)

Footnotes

1. Off the top of my head:
   - All workflows have access to all repo secrets (which would contain a token for arbitrary team changes)
   - Updates to the workflow implementing this should also be restricted
   - Any files the workflow depends on now need extra scrutiny
   - Any committer can manually turn any workflow on/off ↩

[fricklerhandwerk]

Thanks a lot for the elaboration.

[idle comment] All of these items sound to me like constraints that happen to come with GitHub. Too bad we can't make computers do arbitrary things (and a lot of time to make them do exactly what we want)... 😉