Nixpkgs Pull Request Review, Merging, and Channel Flow

If you find anything related that could be improved but is not immediately required for acceptance, consider: - Implementing the changes yourself in a follow-up pull request, - Tracking your idea in an issue, - Offering to review a follow-up pull request, - Making concrete [suggestions](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request) in the same pull request. For example, follow-up changes could involve refactoring code in the affected files. But please remember not to make such additional considerations a blocker, and communicate that to the contributor, for example by following the [conventional comments](https://conventionalcomments.org) pattern. If the related change is essential for the contribution at hand, make clear why you think it is important to address that first. Pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review. All the review templates provided are generic examples. Their usage is optional and the reviewer is free to adapt them. To get more information about how to review specific parts of Nixpkgs, refer to the documents linked to in the [overview section][overview]. If a pull request contains documentation changes that might require feedback from the documentation team, ping [@NixOS/documentation-team](https://github.com/orgs/nixos/teams/documentation-team) on the pull request. If you have enough knowledge and experience in a topic and would like to be a long-term reviewer for related submissions, please contact the current reviewers for that topic. The main reviewers for a topic can be hard to find as there is no list, but checking past pull requests or git-blaming the code can give some hints. ## How to merge pull requests yourself You can invoke the nixpkgs-merge-bot by commenting `@NixOS/nixpkgs-merge-bot merge`. The bot will verify the following conditions, refusing to merge otherwise: - the PR author should be @r-ryantm or a Nixpkgs committer; - the invoker should be among the package maintainers; - the package should reside in `pkgs/by-name`. Further, nixpkgs-merge-bot will ensure all CI checks and the ofborg builds for Linux have successfully completed before merging the pull request. Should the checks still be underway, the bot will wait for them to finish before attempting the merge again. For other pull requests, please see [I opened a PR, how do I get it merged?](#i-opened-a-pr-how-do-i-get-it-merged). In case the PR is stuck waiting for the author to apply a trivial change and the author allowed members to modify the PR, consider applying it yourself. You should pay extra attention to make sure the addition doesn't go against the idea of the original PR and would not be opposed by the author. Please see the discussion in [GitHub nixpkgs issue #321665](https://github.com/NixOS/nixpkgs/issues/321665) for information on how to proceed to be granted this level of access. As a maintainer, when you leave the Nix community, please create an issue or post on [Discourse](https://discourse.nixos.org) with references to the packages and modules you maintained, so they can be taken over by other contributors. # Flow of merged pull requests After a pull request is merged, it eventually makes it to [Hydra](https://hydra.nixos.org). Hydra regularly evaluates and builds Nixpkgs, updating [the official channels](https://channels.nixos.org) when their jobs succeed. See [Nix Channel Status](https://status.nixos.org) for the current channel states. Our primary development branches and their related channels are: - `master`: The main branch, used for the unstable channels `nixos-unstable`, `nixos-unstable-small` and `nixpkgs-unstable`. - `release-YY.MM`: The release branches, used for the stable channels `nixos-YY.MM`, `nixos-YY.MM-small` and `nixpkgs-YY.MM-darwin`. When a channel is updated, its corresponding branch is also updated to the same commit.

This chunk continues guidelines for Nixpkgs pull request (PR) reviews, emphasizing that non-essential improvements should not block a PR but rather be handled separately (e.g., follow-up PRs, issues). Reviews should clearly list what was covered, and specific teams like `@NixOS/documentation-team` should be pinged for relevant changes. The document also details how to merge PRs, introducing the `nixpkgs-merge-bot` for automated merges under specific conditions (author, invoker, package location, and successful CI checks). It also advises maintainers on applying trivial changes themselves if permitted and provides guidance for maintainer departure. Lastly, it describes the 'Flow of merged pull requests,' explaining that merged PRs are processed by Hydra, which builds Nixpkgs and updates official channels (`nixos-unstable` from `master` and `nixos-YY.MM` from `release-YY.MM`) upon successful job completion.