Some incomplete answers:
Even if we wanted to do that, how would we automatically differentiate between minor version bumps and potentially malicious PRs?
That has been part of the solution for a while, but its not working very well. I feel like new committers often tend to lose interest / burn out. Its not infinitely scalable either: each committer is a potential security risk for nixpkgs users.
I think that is the exact opposite of what we need for two reasons:
- we have plenty of people who want to get changes in, not many people who review. Shifting burdon from the first group to the second is not going to help
- the people proposing changes are not going to learn that way
Lack of clear commenting of intentions is one thing. Missing upstream reports another. GitHubs UX yet another.
I still think a process of
- contributor proposes PR, it is tagged with
needs:review
- reviewer reviews, tags with
needs:changes
/ merges / tags withneeds:merge
- contributor makes necessary changes, re-tags with
needs:review
.
Then, we can just automatically close all PRs that have been in needs:changes
for too long and reviewers have a clear place to look.