[RFC 0050] Merge bot for maintainers #50
Conversation
FRidh
changed the title
| # Alternatives | ||
| [alternatives]: #alternatives | ||
|
|
||
| 1. Hand out write permissions more freely. More people will be able to make changes anymore. |
There was a problem hiding this comment.
I much much much prefer this. Have we had any issues because someone was given the commit bit who shouldn't have been, ever? What exactly are we trying to prevent that community norms + git wouldn't give us just as easily?
|
If we're building new tooling, I would instead prefer to go further in the direction of separating review and merge. This could be extended with a bot that allows reviewers to add tags (and committers to filter for them). Alternatively we could take up a sort of mentorship program: Someone that wants to help up teams up with someone with commit permissions. They review PRs and ping their "mentor" when they think its mergable. They take a last look, maybe suggest improvements (thereby teaching the reviewer "on the job"). That may lead to giving the mentee commit permission after a while. However that is also a problem of this approach, as the mentee may feel entitled for this and this may be gamed. Giving any maintainer merge permissions for whatever they maintain without at least having a trusted committer have a last look over it sacrifices too much security in my opinion. |
|
+1. Hand out write permissions more freely. More people will be able to make changes anymore.
I much much much prefer this. Have we had any issues because someone was given the commit bit who shouldn't have been, ever? What exactly are we trying to prevent that community norms + git wouldn't give us just as easily?
I, personally, am trying to prevent people complaining too much about maybe giving commit access too easily, and people not asking for the full access because they think they are not ready for general commit access.
(Also, if someone ends up inspired by RFC and contributing merge functionality for some bot, this brings «merge-if-test-passes» functionality one step closer)
|
This is an RFC, if people have such complaints then they can raise them here and if people have such concerns about their readiness then we can address them here. If we think liberal provision of the commit bit is wrong, fine let's make that case. But if we just think it's a challenging social transition, then let's please not try to address social problems with technical solutions. |
|
To be clear, I'd honestly be happy to have some very general high level guidelines about what to do with commit access (e.g. don't merge to something you don't own without trying to work with the owner first, especially not over their explicit rejection, don't merge anything that breaks automation, operate in good faith, etc.) and then give people access after their first contribution. If people think that's too soon, what specifically is the concern, and has it ever actually materialized in nixpkgs's fairly long history? |
|
This is an RFC, if people have such complaints then they can raise them here and if people have such concerns about their readiness then we can address them here.
Whether they raise them here or not, someone will raise them elsewhere again, eventually.
If we think liberal provision of the commit bit is *wrong*, fine let's make that case. But if we just think it's a challenging social transition, then let's please not try to address social problems with technical solutions.
Replacing a step change with a more gradual change by technical means is quite often a proper part of a (multi-faceted) solution to the social problem of arguing what is the correct threshold.
|
And they will have an RFC process to let them do that.
Sure. If there is disagreement that can't be bridged but there is a change all reasonable sides can agree to, that makes sense. But as far as I know we haven't actually raised this issue in RFC format, which is the right place to try. Do we know we can't actually reach a good outcome here directly? |
|
Is the current process for obtaining commit access detailed somewhere? |
|
@shlevy have you read NixOS/nixpkgs#50105 for example? Also, NixOS/nixpkgs#20836 |
I've been added as committer after reaching the top ~80 contributors and I know from some other people that they were proposed by a committer. Not sure if there's an explicitly defined process though. Regarding the RFC itself: will read through it during the weekend :) |
GitHub added a beta permission level called "Triage" which allows users to add tags. That may be even better than "Read" for @nixpkgs-maintainers. See #39 (comment) |
I hadn't. Why wasn't it an RFC? 😀 |
|
Alright I'll open up my own RFC I guess. 👎 on this one personally unless we really can't get past the current restrictive access otherwise. |
|
The current version of the RFC focuses a bit too much on security. For me the more exiting aspect is that once we have a script to map diffs to maintainers, it will be easier to assign PRs to maintainers as well. And maybe issues even. That will allow to distribute the load quite nicely and reach the right people who have experience with their part of nixpkgs. Security is definitely a concern I have had raised by a few customers. If anyone can merge to master the attack surface is pretty big. Maybe it hasn't happened today but it's naive to think it will never happen as NixOS becomes more popular. |
|
@zimbatm ofBorg already recognises maintainers (except some rare corner cases that are against best practices for other reaons anyway) and requests review. There is a catch that GitHub doesn't allow requesting review from non-member maintainers, and #39 was about fixing that — and Graham has just found time to implement and start deploying the tooling for immediately giving maintainers membership (without immediate write access). So this PR is about a natural next level of tooling: partial write access focused on the packages most likely to get attention-starved. |
|
@FRidh it would be nice to be able to label the PRs I review with something that relates to it's "Ready to Merge". Would also give 2 person accountability to all the merges. |
|
I'm not in favour of extending commit rights more liberally by itself, because I think this makes it even harder to provide adequate security. An attacker can currently simply push a little commit to a nixpkgs release branch without anyone noticing except if someone is actively checking all commits. I'd prefer us to protect all release-* and master branches to only allow commits to them via pull requests or possibly only let a bot push to them after the basic checks (i.e. ofborg) have been run (similar to rust's @bors). Maybe also use the @NixOS/nixpkgs-maintainers group + 2 reviewers necessary github restriction. |
|
I'd prefer us to protect all release-* and master branches to only allow commits to them via pull requests or possibly only let a bot push to them after the basic checks (i.e. ofborg) have been run (similar to rust's @bors). Maybe also use the @NixOS/nixpkgs-maintainers group + 2 reviewers necessary github restriction.
I guess if we require two review _and_ forbid direct pushes, we would need to drastically expand the list of people whose reviews are taken into account… At the same time, watching all PRs will be just as hard as watching all commits right now, and making a person a maintainer requires accepting just a single package from them, so if you want to be paranoid, nixpkgs-maintainers group is too lax for your mission statement.
|
|
|
||
| When these conditions are met the maintainer can write | ||
|
|
||
| @grahamcofborg merge |
There was a problem hiding this comment.
This also means that the source can be altered to anything else, right?
There was a problem hiding this comment.
Correct, within the expression any change could be made.
|
It seems that @GrahamcOfBorg adds the "by package maintainer" as soon as the author of the PR becomes maintainer once the PR merged. It is not required that the author be already a maintainer before. Example: So it should probably be clarified that a maintainer can merge modifications to a package only if they were maintainer before the PR is merged. Or alternatively that a PR which modifies the list of maintainers cannot be auto-merged. |
Rereading the RFC, it seems the PR needs to add me as maintainer of all reverse dependencies as well. |
|
And of course there is also the additional requirement that the «maintainer of all modified packages» check is not in a race condition with reevaluation of pushes, and also the check for modified packages should include some cross-builds (otherwise a change that always changes one package and a lot more for corss-builds will be handled weirdly) |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/nixos-package-information-platform/3787/1 |
|
This RFC is open for shepherd nominations, please bring forward nominations (might include yourself). Quoting RFC #36 for the responsibilities of the shepherd team: Shepherd TeamA team of 3-4 community members defined unanimously by the RFC Steering Committee, responsible for accepting or rejecting a specific RFC. This team is created per RFC from community members nominated in the discussion on that RFC. This team should be people who are very familiar with the main components touched by the RFC. The author cannot be part of the Shepherd Team. In addition, at most half of the Shepherd Team can be part of the RFC Steering Committee. The responsibility of the team is to guide the discussion as long as it is constructive, new points are brought up and the RFC is iterated on and from time to time summarise the current state of discussion. If this is the case no longer, then the Shepherd Team shall step in with a motion for FCP. Shepherd LeaderThe person in charge of the RFC process for a specific RFC, and responsible for ensuring the process is followed in a timely fashion. The Shepherd Leader has no special responsibility with regard to moving an undecided Shepherd Team to a certain decision. |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/new-rfc-50-merge-bot-for-maintainers/3795/1 |
|
Unfortunately, GitHub not warning in any way when you answer with an email that a post that you answer for is already removed. So, it'll be strange for me to defend a deleted comment that was the result of my misread. However, @jtojnar, you cannot trust previous version bumps anyway because not all of the nixpkgs-committers actually checking what they merge. Just like not all of the people who make a pull request and checkmark "I've tested what I did" actually testing it. @timokau, there was no idea to merge it "checking that only version and sha256 are changed". It was a bit more complicated. Anyway, the RFC assumes that the package maintainer will be able to merge his packages, which means from a security model point of view there's no difference. |
|
@worldofpeace certainly. @FRidh @grahamc @worldofpeace I would like to schedule a quick call so we can regroup on this. Seeing as it is already Tuesday and this is an office hours week I don't expect everyone to be available this week but I really hope everyone can make 30 minutes available before the end of next week. @FRidh I believe aside from you the rest of us are in EST (or somewhere close to). Can everyone post a few desired times or time ranges for the next 2 weeks please? |
|
ping @FRidh @grahamc @worldofpeace on availability |
|
Next week monday at 10am EST would be good for me (I also thing that would be the afternoon for @FRidh) How about we do a https://doodle.com/create/? |
Sorry for pinging you all, but may I suggest framadate (there are instances at https://framadate.org/ and https://poll.disroot.org/)? Unkike doodle it doesn't share your data with literally hundreds of third parties, it has no ads, and it's free software. |
|
ping @FRidh @grahamc @worldofpeace on availability via link below. https://poll.disroot.org/8lXUangUAt2jNR5q Let me know if these don't work out and what date+times work better for you. |
|
@aanderse Did it |
|
None of the options worked for everyone so I have posted a new poll with new suggested times. ping @FRidh @grahamc @worldofpeace with https://poll.disroot.org/8lXUangUAt2jNR5q |
Completed. |
|
I am reducing the amount of time I spend on NixOS/Nixpkgs and this RFC is not very high on my priority list so I intend to close this unless someone is willing to take it over. The main thing that still had to be done was to create a flow chart. |
|
@FRidh Closed. |
|
@worldofpeace agreed, if only I had infinite time I would pick this up :( |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/steps-towards-even-more-pr-automation/5634/13 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/stats-trends-on-github-issues-prs/7936/36 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/how-many-people-are-paid-to-work-on-nix-nixpkgs/8307/24 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/misuse-of-commit-permissions/10071/38 |
An RFC for having a bot that allows maintainers to merge their changes to Nixpkgs. I think this can help a lot to reduce the load on nixpkgs-committers by letting maintainers of leaf packages merge their own changes, however, there is also a big security risk.
I think the latter outweighs the former. Even so, I hope this RFC can help us further in our quest on how to scale Nixpkgs either by directly offering a way to reduce load on the nixpkgs-committers, or by agreeing to not pursue a certain option.