Don't run all core tests with every patch

Disclaimer: Sorry if this is in the wrong queue, I have absolutely no clue where the code that this would potentially change lives.

Core development is very cumbersome currently because of the long time it takes to run tests. Running them locally takes hours, and even the testbot takes about 30 minutes per patch currently. Depending on how many iterations you need to get the patch right, that can turn into an awful lot of time.

I co-maintain Libraries API and running those tests locally takes (literally) 3 seconds, which makes test-driven development possible and useful for that project. In theory this works for development on drupal.org as well, because in theory core tests are not run for contributed modules. (The fact that this is currently not the case is a bit frustrating, but not related to this issue.) Which makes a lot of sense, because whatever we do in Libraries API we will never break core tests (please don't take that as a challenge!).

So that had me thinking about core. Say, I have a patch that fixes some help text in Poll module. Similar to the above, there is no way on earth that my patch is going to break Color module, for example. Yet, it is run among others against Color module's tests. And if it takes me 3 tries to get the patch right, it is run against Color module's tests 3 times. That doesn't make a whole lot of sense. So the proposal is at its simplest if we can find a way to not run those tests. (Of course not running Color module tests is easy, whether or not to run which tests is the hard part.)

Now this doesn't apply to all patches, of course. Patches that change bootstrap.inc probably should be run against all tests. Another thing to consider is dependencies, more specifically reverse dependencies. A change to Node module can very reasonably break Book module or Blog module, so it would make sense to run those tests for such a patch. There are also probably a lot of other things that I haven't considered, for instance what happens with patches to themes or profiles. But I think the motivation and the initial example are reason enough to seriously consider if something like this is not feasible.

So my initial proposal would be something like this:
For each patch against Drupal core:
- Have a suite of tests that always run (tests of includes, etc.)
- Check which modules the patch changes
- Gather a list of all these modules including their reverse dependencies
- Run only the tests of those modules