The Nixpkgs core team has been quite busy since our last update about unexpected problems with the Nixpkgs repository on GitHub. The most significant developments have been:
-
After talking with the committer delegation team, we have taken over responsibility of the process for now, due to the previous team’s lack of time. In line with our previously‐announced hopes to improve the consistency and documentation of standards for contributors and committers and reform the Nixpkgs commit bit procedures for increased transparency and quicker decisions, we have now cleared the backlog of new committer applications since August, and published a set of guidelines for how we intend to manage both addition and removal of committers.
-
We had our second call with GitHub on Monday, and confirmed that the acute maintenance problem we discussed in our last update has been solved thanks to actions on GitHub’s end.
There is still some drift between replicas, but it is now within relatively normal parameters. We are working with GitHub to diagnose this further to get the Nixpkgs repository as healthy as possible; per their request, we have started an experiment to temporarily skip the PR mergeability checks used to assign the merge conflict label in CI, and hope to hear soon about whether the reduced updates to Git references have had a measurable impact on their metrics so that we can pursue possible further improvements.
We also took the opportunity to discuss some API issues we recently ran into around querying per‐user PR merge activity when using the merge queue and querying commits by certain usernames; we have filed tickets for these and are working to get them escalated through our points of contact at GitHub.
This led to an offer from our point of contact to look into starting the process of applying for sponsored GitHub Enterprise Cloud, which provides an audit log API that could help with the committer retirement automation that ran into these bugs, and which has been discussed before due to the fine‐grained permissions it would enable and the increased limits (most notably around the maximum number of reviewers for a PR and GitHub Actions rate limits and concurrency limits). We hope to actively pursue this thanks to the various benefits it would offer even if the API bugs get fixed.
-
We have reviewed the matter of corporate maintainer teams in Nixpkgs in response to a request, and posted a detailed response recommending that, in line with established practice in most aspects of Nixpkgs development, our written project values, and precedent from Linux kernel maintenance, participation in package maintainership should be on an individual basis, with teams organizing around specific areas of expertise and maintenance focus rather than corporate employment. We are of course very happy for companies to sponsor maintenance work on Nixpkgs and hope to see more of it, but feel that assignment and revocation of maintainer authority and organization of teams should be a matter for Nixpkgs, rather than being delegated to an external corporation based on its employment decisions.
As always, we can be reached publicly or privately to answer questions, discuss concerns, or have Nixpkgs matters escalated to us.