I’d love to see a solution here that moves us away from rollups - I find them a pretty frustrating solution due to the bad prioritisation they cause - as noted in the blog, and also because PRs which are likely to have higher impact on the user (because they are large, complex, or high risk) are de-prioritised.
I think it is worth planning the long term solution now - it’s a big job and not user-visible, so there is not much energy for it when it is non-urgent, but when it is urgent (like now) we don’t want to think about the long term because we need a short-term solution. My preferred long-term solution is to split the repo and have two-stage landing. This gets us the quick satisfaction of landing PRs without them blocking unrelated PRs, and it has the advantage that it scales.
In the short-ish term, I think we could do much better if we allow PRs to run subsets of the tests. For example, most documentation changes don’t need to run any tests at all. Those that touch examples only need to run doc tests, they don’t need to rebuild the compiler and run the whole test suite. Changes to a tool, only need to run that tool’s tests, etc. (Although if we do split the repo, then this becomes wasted work).