-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automate the r=me idiom #39
Comments
r=me is explicitly blacklisted because it could also mean We could add a different opt-in command for like We could add a forced pre-check after r+ before testing the PR:
The reviewer can opt-out the Travis PR check by One difficulty with automatic r+ is that a CI vendor may spuriously unable to update the GitHub status, keeping the PR forever in yellow. Also, it's hard to verify the correctness without a test framework 🤷♀️ |
Sure, that sounds good. The actual command isn't that important to me.
Maybe... that seems like a more invasive change that might be annoying when doing rollup ops or when accepting obviously passing PRs. I think |
We talked about this again recently. |
There's a possibility that fixing CI leads to "oh this requires a lot more changes". So a final explicit approval should always be required IMO. r=me works well as "I trust you to approve given that additional changes are minor". |
My idea of how this feature ( |
That makes more sense. Or it could be default behavior and opt-out with |
Oftentimes reviewers will write something like
r=me with green travis
.It would be good to automate this sort of thing such that a reviewer can write:
and then bors will r+ once travis is actually green.
That way, you don't need any other reviewer to intervene or to delegate bors privileges.
The text was updated successfully, but these errors were encountered: