nixpkgs update review 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.
Loading the queue.
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.
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.