Honestly the test is completely unreadable. There is no way I can ensure this is correct.

I accepted the other one.

Considering this is for testing, ti doesn't need t be constant time and all.

Just redo the diff, instead of reverting a revert. Actual patch can be the same, but people don't need to play detective afterward.

This diff suffer from the classic syndrome of doing several things at once, causing discussion about one of these things to delay progress and all the others and everybody getting frustrated.

There are no tests.

The synchronization is still incorrect.

This is getting better, but you need to pay attention to the mempool admission code and the memppol maintenance during reorg.

While this is good to do per se, I'd rather not do that when everybody is trying to get the features for the May's upgrade in place. Please request review for this after Feb, 15.

This shows all the sign of code that has been banged on until it more or less passes some smoke test.

1. Show the mechanism is not adapted. If 99% of the possible of a tool are shooting yourself in the foot, then that means the tool is badly design, end of story.
2. If the intended use case is to be able to check the state of the test suite post activation, then it fail flat on its face as random tests will not do it, silently.

Are you running into something that requires this ?

I don't think making hacks more accessible is really a great idea.

Clearing my queue.

This illustrates one more problem for D2459 . What if one doesn't want 127.0.0.1, for instance to test for bans?

ninja will by default create as many jobs as it thinks your machine can take.

I really fail to see what's the goal here.

Reaching feature parity with the configure/make build. To the contrary, this makes them divergent.

None of this is doing what the test plan says it does. Have you really tested this ?

They already run as part of check-all

rebase