nixpkgs update review queue
Ready to act
Low risk, CI passed and 10 rebuilds or fewer, not in the merge queue and without a merge request yet. These are the updates you can act on first.
Loading the queue.
Browse all updates
More filters (3 on)
About this queue
About 3,300 open pull requests in NixOS/nixpkgs update one package each, and most come from the r-ryantm bot. This queue reads them from GitHub every 5 minutes and sorts out the routine ones.
Each update gets a risk level from fixed rules: the version change, the rebuild counts, CI, nixpkgs-review and the lines of the diff that are not version or hash lines. Filter the queue, open a brief, then review on GitHub.
See the stats of all open updates: who they wait on, CI and risk.
Questions
What does nixpkgs-ctl show?
It shows the open pull requests in NixOS/nixpkgs that have the label 8.has: package (update). Each card has the version change, a risk level, the rebuild counts for Linux and Darwin, the CI result and the approvals on the head commit.
How is the risk level found?
Fixed rules, not a language model. A major version, 500 rebuilds or more, a stdenv rebuild, a removed patch, a licence or source change, a CI failure, a merge conflict or a failed nixpkgs-review make the risk high. Only version and hash lines, at most 10 rebuilds, a patch or minor version, CI success and the version found in the output make it low. Everything else is medium.
Which lines of a diff are trivial?
Lines that set version, rev, tag, hash, sha256, vendorHash, cargoHash or npmDepsHash, and a line that changes only by the version number. The brief highlights every other changed line.
Do I need to sign in?
No. Type your GitHub username to see your queue: the updates you opened, the packages you maintain and the reviews people asked of you. The username stays in this browser. The app reads only public data.
Can I approve or merge from the app?
No. The review sheet has your checklist, the link to the changed files on GitHub and two commands to copy: nixpkgs-review pr N --post-result and @NixOS/nixpkgs-merge-bot merge. You approve and comment on GitHub.
Where are the numbers for all updates?
The stats page counts all open updates: who they wait on (the author, CI, a maintainer, a committer or a review from anyone), how many can merge now, CI results, risk, rebuild size and the packages with most open updates. The app counts them again once an hour.
What are a maintainer, a committer and a reviewer?
A maintainer is a person in the meta.maintainers list of the package. With the merge bot, a maintainer can merge an r-ryantm update of a package under pkgs/by-name by commenting @NixOS/nixpkgs-merge-bot merge. A committer is a member of the NixOS nixpkgs-committers team. A committer can merge any PR. A reviewer can be anyone. A review from anyone helps. An approval from a maintainer or a committer counts for a merge. The app cannot see who is a committer, because GitHub does not show that team list to it.
Is everything here deterministic?
Yes. Every label, risk level, waiting state and duplicate verdict comes from fixed rules on GitHub data. The app uses no AI and no language model. Only "Give me one" picks at random among good first reviews, so two people do not get the same pull request.
How does the app choose which duplicate to close?
When a package has more than one open update, the app applies six rules in order. A stable version beats a prerelease. The higher version wins. With the same version, the PR without a merge conflict wins, then the one whose CI did not fail, then the one with more approvals, then the newer one. The other PRs are the ones to close.
How fresh is the data?
The app reads GitHub every 5 minutes. A brief shows the data of the last read, and the link to GitHub always shows the live pull request.
How do I open any nixpkgs pull request here?
Open any nixpkgs PR here: replace github.com with nixpkgs-ctl.kamadorueda.com in the address. For example, github.com/NixOS/nixpkgs/pull/123456 becomes nixpkgs-ctl.kamadorueda.com/NixOS/nixpkgs/pull/123456. The app shows the PR only if it tracks it: update PRs with the label 8.has: package (update).