2020-10-23, Future of and by RFC79
| Attendees | Role |
|---|---|
| dasJ | RFC author |
| matthiasbeyer | RFC co-author |
| @kevincox | author Draft Merge Queue RFCs |
| @7c6f434c | project memory |
| @lschuermann | participant |
| @blaggacao | moderator |
Outcomes
- Although the general direction was not dropped, the RFC was closed
copying over from this comment
- With the current workflow simply requiring PRs for all changes will create unsustainable maintainer burden.
- The security benefit of having multiple approvers is desirable however would cause a substantial human cost that nixpkgs can’t afford right now.
- We should consider approaches to make reviews easier for the maintainers, in the hopes that it will allow us to pay this cost in the future.
- We could consider an auto-merge bot that can merge with rules such as the following:
- 2 approvers in the maintainers team allows merging.
- Approval from maintainers of all affected packages allows merging. (Including self-merge!)
- Approval from the maintainer of the root affect package and min(count(maintainers(afected packages), log(affected packages)) additional approvals.
- Better pre-merge testing can free some time that maintainers currently spend debugging hydra failures.
- Last but not least, it motivated me to push for the conformation of SIG Workflow automation