Home Explore Blog Models CI



nixpkgs

3rd chunk of `maintainers/README.md`
e7ecd02cab0aaefadb1f5ecf08551c18d8f8782072ab3c9c0000000100000bd2
      gpg: Total number processed: 1
      gpg:               imported: 1

  Then check the commit is signed by that key:

      $ git log --show-signature
      commit b87862a4f7d32319b1de428adb6cdbdd3a960153
      gpg: Signature made Wed Mar 12 13:32:24 2003 +0000
      gpg:                using RSA key 000000002A7064230AED3C11F04F7A19AAA63AFE
      gpg: Good signature from "Example User <user@example.com>
      Author: Example User <user@example.com>
      Date:   Wed Mar 12 13:32:24 2003 +0000

          maintainers: adding example

  and validate that there is a `Good signature` and the printed key matches the user's submitted key.

  Note: GitHub's "Verified" label does not display the user's full key fingerprint, and should not be used for validating the key matches.

- Ensure that the user has specified a `github` account name and a `githubId` and verify the two match.

  People can and do change their GitHub name frequently, and the ID is used as the official and stable identity of the maintainer.

  Given a maintainer entry like this:

  ``` nix
  {
    example = {
      email = "user@example.com";
      name = "Example User";
      github = "ghost";
      githubId = 10137;
    };
  }
  ```

  First, make sure that the listed GitHub handle matches the author of the commit.

  Then, visit the URL `https://api.github.com/user/10137` and validate that the `login` field matches the provided `github` handle.

### Maintainer teams

Feel free to create a new maintainer team in [`team-list.nix`](./team-list.nix) when a group is collectively responsible for a collection of packages.
Use taste and personal judgement when deciding if a team is warranted.

Teams are allowed to define their own rules about membership.

For example, some teams will represent a business or other group which wants to carefully track its members.
Other teams may be very open about who can join, and allow anybody to participate.

When reviewing changes to a team, read the team's scope and the context around the member list for indications about the team's membership policy.

In any case, request reviews from the existing team members.
If the team lists no specific membership policy, feel free to merge changes to the team after giving the existing members a few days to respond.

*Important:* If a team says it is a closed group, do not merge additions to the team without an approval by at least one existing member.


# Maintainer scripts

Various utility scripts, which are mainly useful for nixpkgs maintainers, are available under `./scripts/`.
See its [README](./scripts/README.md) for further information.

# nixpkgs-merge-bot

To streamline autoupdates, leverage the nixpkgs-merge-bot by commenting `@NixOS/nixpkgs-merge-bot merge` if the package resides in pkgs-by-name, the commenter is among the package maintainers, and the pull request author is @r-ryantm or a Nixpkgs committer.
The bot ensures that all ofborg checks, except for darwin, are successfully completed before merging the pull request.

Title: Nixpkgs Maintainer Verification, Teams, and Merge Bot Usage
Summary
This chunk details further verification steps for Nixpkgs maintainers, including confirming GPG key signatures on commits and verifying GitHub account names against their stable GitHub IDs using the API. It introduces the concept of maintainer teams in `team-list.nix`, explaining how to create them, define membership rules, and review changes to team rosters, stressing the importance of approval from existing members for closed groups. Finally, it provides specific instructions for maintainers on how to leverage the `nixpkgs-merge-bot` for streamlined autoupdate merging, outlining the conditions required for its activation and its role in ensuring successful checks before merging pull requests.