Describe the rollup process #87
Conversation
performing-a-rollup.md
Outdated
|
|
||
| Enter rollups - low risk changes (often doc fixes or other non-functional changes) | ||
| are marked with the `rollup` command to bors (e.g. `@bors r+ rollup` to approve a | ||
| PR and mark as a rollup or `@bors rollup` to mark a previously approved PR). |
There was a problem hiding this comment.
Not sure if you want to mention rollup- which removed the rollup flag
aidanhs
force-pushed
the
aphs-rollup-details
branch
from
4bd9e3e
to
93465df
Compare
performing-a-rollup.md
Outdated
|
|
||
| The Rust project has a policy that every PR must be tested after merge before it can | ||
| be pushed to master. As PR volume increases this can scale poorly, especially given | ||
| the 2hr30min current CI duration for Rust. |
There was a problem hiding this comment.
"long" seems better as this is constantly changing.
performing-a-rollup.md
Outdated
| - Visit https://buildbot2.rust-lang.org/homu/queue/rust. | ||
| - If there are >= 10 rollup priority PRs, you should probably create a rollup. | ||
| - Look at the current PR being tested: | ||
| - If it has a priority >0, do not create a rollup until it's complete. |
There was a problem hiding this comment.
This feels like it should be based on the approved queue.
There was a problem hiding this comment.
So ">= 10 rollup priority PRs" -> ">= 10 approved rollup priority PRs"? That is what I meant to say, but want to check you're not looking for something else.
There was a problem hiding this comment.
Ah, that too, but what I meant is that instead of "current PR being tested" we should base this off of the whole queue, I think, or at least the PR being tested and the next PR in the queue.
performing-a-rollup.md
Outdated
| - (first time: Authorise the github permissions) | ||
| - Wait for a minute while the rollup is created on the `rollup` branch of your repo | ||
| and the PR is submitted for you. | ||
| - Comment with `@bors r+ p=1`. This will put the PR above any 'normal' PRs, but |
There was a problem hiding this comment.
Hm, I tend to use p=10 for rollups, 1 for things that we want to land soon, and 100 for PRs that need to land next. Open to changing this, though, it's not really based on logical thought, just what I've arrived at over time.
performing-a-rollup.md
Outdated
| below 'urgent' PRs. | ||
| - Comment on the PR currently being tested with `@bors retry`. This will prompt | ||
| bors to stop the current test, allowing it to pick up the new top of the queue - | ||
| the rollup. |
There was a problem hiding this comment.
Why? Rollups should never be urgent...
There was a problem hiding this comment.
I think this isn't written well. When I say "This will put the PR above any 'normal' PRs, but below 'urgent' PRs." I mean "r+ with p=1 (or 10) will put the rollup PR above any 'normal' PRs with just an r+, but below urgent PRs, e.g. with p=100, that need to land asap".
How would you rephrase this?
There was a problem hiding this comment.
I think that line is fine. I was confused why we would @bors retry a PR already being tested to prioritize a rollup; that doesn't seem advantageous to me.
There was a problem hiding this comment.
Oh, just to avoid merge conflicts when it's the rollup's turn (bors is sometimes overcautious with merging). Indeed, they're not important hence why I say something like "don't cancel a PR that's been running for a while".
There was a problem hiding this comment.
Ah. I've rarely seen merge conflicts in a rollup, I think, but I'm not sure this is worth noting here -- to me, if we have to re-rollup that's not really all that bad.
There was a problem hiding this comment.
To be honest I had just seen it somewhere else and decided to include it here e.g. rust-lang/rust#42592 (comment), rust-lang/rust#41279 (comment), rust-lang/rust#41311 (comment)
Any thoughts on this @frewsxcv?
There was a problem hiding this comment.
It's a subjective call. For the most part, I usually don't interrupt the current PR being tested unless that PR is included in the rollup or the rollup hit a spurious failure and needs an immediate retry
performing-a-rollup.md
Outdated
| Close the PR, figure out if the failure was spurious - if so, create a new PR, | ||
| if not, find the possible candidate PR(s) and unmark it (them) as rollups with | ||
| `@bors rollup-`, commenting on the PR with the error. Hopefully the author or | ||
| a reviewer will give feedback to get the PR fixed or confirm that it's not at |
There was a problem hiding this comment.
r- seems prudent as well.
aidanhs
force-pushed
the
aphs-rollup-details
branch
from
93465df
to
377a2ec
Compare
|
Updated based on comments. Rollups are now left to naturally reach the top of the queue, and the only factor in creating a rollup is the number of rollup PRs ready to go. |
|
|
||
| ## Failed rollup | ||
|
|
||
| Close the PR, figure out if the failure was spurious. If so, create a new PR, |
There was a problem hiding this comment.
If the failure is spurious, @bors retry seems appropriate; not closing the PR.
There was a problem hiding this comment.
There are a bunch of different possible approaches, and I don't mind which. Which of the following do you prefer?
- always a new rollup
- retry on spurious failure
- retry on spurious failure, unless there have been additional rollup-approved PRs created
- retry on spurious failure, also retry the current PR running if it's p<10 and has been running <N minutes
- 3 + 4
- [insert other here]
|
@aidanhs Hello, unfortunately the project layout has changed such that we can no longer merge this PR in current state. If you have the time would you be able to update this or make a new PR? |
|
Closing this in favor of #268 |
Thoughts @Mark-Simulacrum @frewsxcv?