I’ve noticed complaints about bors times. I noticed them myself. I have an idea for improvement I’d like to share.
In my opinion, it is not the time it takes for a correct branch to get merged which is the problem. The problem is when there are failing tests and when one needs to iterate fixing it ‒ each iteration takes a day or so.
This takes so long because the requests wait in line and are processed serially. But if there was enough computing power (actually, I have no idea if there is), an accepted branch could get tested right away. It could work like this:
- If a branch is approved, take the current master and the branch, merge them in a separate temporary branch and run tests. It is the same as now, just it wouldn’t wait for a slot and run it in parallel (maybe with some limit on how many parallel builds there can be).
- If it fails, the author knows about the problems much sooner, so it is possible to iterate faster. Most of the pain point is eliminated.
- If it succeeds, it can’t be put into master, because likely there was something else in the meantime that moved master. However, the chance of this PR causing a failure is now much smaller. The PR moves to a 2nd queue.
- The 2nd queue either works just as now (with the contention around master, so it needs to wait), but with better success rate, most PRs will wait this queue just once. Or, if the success rate is good enough, it could be doing automatic roll-ups of everything that is in the queue each time it starts a build (and fall back to some other algorithm if it still fails).
Does that make sense? If so, what are the steps that need to be taken if this is to happen? Does bors also follow the RFC process, or should I go ask someone specific? Sorry if this is documented somewhere, but I found only a repository with the last commit in 2014.