diff --git a/sig-scalability/block_merges.md b/sig-scalability/block_merges.md index d57c68a17..fdc73c1d4 100644 --- a/sig-scalability/block_merges.md +++ b/sig-scalability/block_merges.md @@ -7,8 +7,11 @@ from merging into the relevant repos. This document describes the underlying ### Rules of engagement. The rules of engagement for blocking merges are as following: -- Observe as scalability regression on one of release-blocking test suites. -- Block merges of all PRs. +- Observe as scalability regression on one of release-blocking test suites + (defined as green to red transition - if tests were already failing, we + don't have a right to declare a regression). +- Block merges of all PRs to the relevant repos in the affected branch, + declaring which repos those are and why. - Identify the PR which caused the regression: - this can be done by reading code changes, bisecting, debugging based on metrics and/or logs, etc. @@ -19,7 +22,7 @@ The rules of engagement for blocking merges are as following: - reverting the PR - switching a feature off (preferably by default, as last resort only in tests) - fixing the problem (if it's easy and quick to fix) -- Unblock PR merged. +- Unblock merges of all PRs to the relevant repos in the affected branch. The exact technical mechanisms for it are out of scope for this document. @@ -34,7 +37,8 @@ if we want kubernetes to maintain scalability SLOs. The reasoning is: - once a regression is merged, and no other action is taken, it is only a matter of time until another regression is merged on top of it, - debugging the cause of two simultaneous (piled-up) regressions is - exponentially harder, see issue 53255 which links to past experience + exponentially harder, see issue [53255](http://pr.k8s.io/53255) which + links to past experience - we need to keep flakiness of merge-blocking jobs very low: - regarding benchmarks, there were several scalability issues in the past caught by (costly) large-scale e2e tests, which could have been caught and