Repository navigation
Conversation
|
Stats table, for those who would like it(no shame in not having run this, fwiw)
Generated with https://gist.github.com/pbsds/7af827a53c103cd3d40902f9b0b21843. |
There was a problem hiding this comment.
I went looking through Nixpkgs for how Sam works rather than just summing to a count. I found that he already practice the committer responsibilities, so I'm putting a ✅ on this PR. I'll wait to merge until the one-week feedback window closes on 2026-10-09.
- He teaches rather than just corrects. His reviews explain the root cause, link the exact source lines, and end with a patch he's already built. Take his
locale_tdiagnosis for a first-time contributor. Or NixOS/nixpkgs#515614, where he stayed with a newcomer through many rounds and closed with "hopefully in your future PRs you'll have an easier time now that you know how to properly deal with hashes in fixed-output derivations." That's people come first. I love to see it. - He defers and doesn't gate. "I'll defer to @eclairevoyant though." "Can't comment on the NixOS module but the package looks reasonable." That's distribute decisionmaking widely. And it's treating everybody with kindness and respect.
- He takes feedback and fights fairly. "Done! I apologize for not looking more closely at this when I opened the PR." When he disagrees he brings evidence, and reviewers have changed their minds because of it (1, 2, 3).
- He upholds quality without inventing standards. When others wanted NixOS/nixpkgs#521971 merged, he pointed out that the test would just start failing again in a year. He asks authors to follow the written AI-disclosure policy (1, 2), and he follows it himself.
npbas a tool is automation over toil. It answers the question a reviewer actually has: did this PR break it, or was it already broken? It answers reproducibly, on platforms the author may not have.
There are two things I'd ask Sam consider when he holds the commit bit, both under "you are responsible for what you merge":
- In NixOS/nixpkgs#455100 (long time ago now), he said he didn't trust the patch and couldn't review it. That's fine to say as an author. It isn't fine as the person pressing merge. A committer who can't vouch for a diff, AI-written or otherwise, should find someone who can before it lands.
- Attention is the scarcest resource in Nixpkgs. @OPNA2608's note on drive-by build reports and @willcohen's note on parallel PRs make the same point: every comment and PR should move a thread toward a merge. With commit access Sam can carry a PR the whole way, which is exactly why he asked for it.
If you've worked with Sam and have something to add, for or against, please say so here before the 9th.
iedame
left a comment
There was a problem hiding this comment.
I've collaborated with @samestep multiple times in Nixpkgs (both giving and receiving reviews). In every interaction, they've shown great respect and a strong attention to detail.
We definitely need more committers who go beyond just infrastructure or core packages and actively engage with the human side of the project: people who genuinely enjoy reviewing PRs and helping clean up the tree.
There was a problem hiding this comment.
I worked with @samestep in samestep/npb#2 and samestep/npb#3, and I was incredibly impressed with how he engaged in those discussions, with his thoughtful consideration and with his attention to detail.
As @philiptaron said, I think Sam is already demonstrating the qualities we need in folk who have commit privileges.
MattSturgeon
left a comment
There was a problem hiding this comment.
I can't personally vouch for @samestep, but I am convinced by the testimonials so far, along with plenty of thorough and friendly interactions in the PRs their involved with, which align well with the role of a committer. As always, we'll wait at least a week for community feedback before making a final decision.
Hello! I would like to nominate myself to be a Nixpkgs committer so that I can justify spending more of my spare time reviewing Nixpkgs PRs.
I've enjoyed participating in ZHF for the 25.11 and 26.05 release cycles (and am looking forward to doing so again for 26.11), but felt a desire for different tooling, so a couple months ago I built
npbas a tool to make debugging Nixpkgs build failures less error-prone. My original intention was to use this tool on my own PRs to certify that they don't cause build failure regressions (and I have been using it for that), but it turned out to also be very useful for providing reproducible patches in feedback comments when reviewing others' PRs:(I have also been happy to see other regular Nixpkgs contributors start to adopt
npb, such as @mdaniels5757, and also @me-and who was recently nominated in #137.)I would like to do a lot more of this, but I do not feel that I can currently justify spending the amount of time that it takes for me to do this for a PR, given that in practice it is fairly unlikely that the PR will eventually be merged even if the author is responsive.
Thus, I would like to have commit access so that it would be a more worthwhile use of my time to shepherd others' PRs.