Hello Nix community,
We’re thrilled to introduce the nixpkgs-merge-bot committer pull request merge strategy. It allows maintainers of a package to merge pull requests created by people who have write access to nixpkgs (nixpkgs-committers).
The strategy is going to be enabled in the next couple days and can simply used by maintainers by commenting:
@NixOS/nixpkgs-merge-bot merge
If you have any good ideas, feel free to open an issue.
Stay tuned for updates as we continue to improve! 
Thank you very much!
It’s worth mentioning the current constraints (quote):
pkgs/by-name/*.master, staging, and staging-next branches.Thanks for the hint, to clarify:
For now we only allow pull requests done by r-ryantm and committers to be merged
I’m not sure how useful it is for maintainers to be able to merge committers PRs, but I can’t see any real disadvantages to that, so I think this is totally fine and an happy for the small win 
Just to highlight, the previous annouuncement said that any substantial changes to the bot will be done via RFC (which this here is arguably not). And this RFC already exists with more substantial extensions to the bot.
Ah we discussed this at 38c3 briefly. The idea is, that this is just easing a workflow we already have implicitly, so we can just codify it instead of discussing it more. The RFC should still be discussed and we need to find another date soonish for that 
Hm, I’m not sure how I feel about this.
Among committers there is somewhat of a culture of not being too hasty with merging that might not be shared among the broader maintainer base; perhaps merging prematurely when the committer author had intended to have a few more eyes on something or sleep over it.
PRs I open can often be in this sort of semi-draft state where I wouldn’t be mad if someone merged it prematurely but also would have preferred to have it cook a little longer. IME we’re rarely explicit about this sort of thing because it’s sort of a cultural norm.
OTOH it always is a change regarding a package which the non-committer maintains, so they likely have a closer relationship with the committer/author or can tell better how obvious it is that a change is good.
Despite my reservations I think we should at least try this out.
As I see it, the intention behind the restriction to r-ryantm was to ensure the commits are made by a trusted source and committers are of course all trusted.
PRs I open can often be in this sort of semi-draft state where I wouldn’t be mad if someone merged it prematurely but also would have preferred to have it cook a little longer. IME we’re rarely explicit about this sort of thing because it’s sort of a cultural norm.
In my experience its best to avoid ambiguity and just open the PR as a draft in this scenario.
I think there are some disadvantages of “draft” for this situation like not pinging code owners.
Okay, open as regular PR, then move back to draft Relying on implicit rules makes nixpkgs worse to participate in for new contributors.
As often is the case, this is of course a tooling issue but that doesn’t mean it’s not an issue or that the implicit rules aren’t the status quo.
Might be a stupid question but how would one know whether a user is a commiter?
Edit: okay Sign in to GitHub · GitHub
Can confirm that this did not explode horribly!
You have to be part of the nixos org on github to know what teams people are part of. And then you’d be able to see if they’re in the NixOS/nixpkgs-committers (sp?) team or not.
Though worst case, you can still comment for merge, and if they’re not a committer, the merge just won’t happen (with an explanatory error comment).
I think this no longer applies after https://github.com/NixOS/nixpkgs/pull/347610 right? Not sure how pings happen now but its not happening via GH automatically anymore.