Often PRs come through where one can be highly confident, or even certain, that the PR will not cause test failure. (e.g. documentation that is not tested, typos in comments, Vim syntax files for Rust.)
At the simplest level, optimism would just be a boolean flag: that if a developer is optimistic that a patch will land successfully, it can merge multiple optimistic patches at once.
A slightly higher level of implementation for this feature would be a parameter optimism=X, for values of X between 0 and 1 (inclusive).
optimism=1 means "there is no way this can genuinely go wrong" which would also mean that you could merge it with a non-optimistic patch and impute no failure to this patch in case of failure, and so immediately put it back in the approved queue rather than the bad queue. If it fails three times (arbitrary number), mark it as bad, just in case the optimism flag was erroneous. @retry isn't hard in such cases.
You could let optimism=0.99 merge only with other optimistic patches.
After that, you could get into moderately advanced statistics, if you wanted—probability that a patch will land, and then let bors calculate potential time savings by merging multiple patches at once (win if they land; lose if they don't, and then it can take a guess at which broke it and try a smaller set of patches). Artificial intelligence! Machine learning! Fun!
But for the moment, basic optimism checking would be a good feature to have.
Often PRs come through where one can be highly confident, or even certain, that the PR will not cause test failure. (e.g. documentation that is not tested, typos in comments, Vim syntax files for Rust.)
At the simplest level, optimism would just be a boolean flag: that if a developer is optimistic that a patch will land successfully, it can merge multiple optimistic patches at once.
A slightly higher level of implementation for this feature would be a parameter
optimism=X, for values ofXbetween 0 and 1 (inclusive).optimism=1means "there is no way this can genuinely go wrong" which would also mean that you could merge it with a non-optimistic patch and impute no failure to this patch in case of failure, and so immediately put it back in the approved queue rather than the bad queue. If it fails three times (arbitrary number), mark it as bad, just in case the optimism flag was erroneous.@retryisn't hard in such cases.You could let
optimism=0.99merge only with other optimistic patches.After that, you could get into moderately advanced statistics, if you wanted—probability that a patch will land, and then let bors calculate potential time savings by merging multiple patches at once (win if they land; lose if they don't, and then it can take a guess at which broke it and try a smaller set of patches). Artificial intelligence! Machine learning! Fun!
But for the moment, basic optimism checking would be a good feature to have.