I'm not so sure what we argue about here. The hypothetical case that it's hard to hook things up for build testing early, right? I've haven't seen that yet.
Let's step back for a moment. The proposal as I understand is that all code that lands in the tree must be hooked up so it's built by Jenkins, correct?
That sounds good at first, but comes with a lot of ramifications. One example, if I'm understanding your proposal, is that one can no longer commit some initial SOC support followed up some time later by a mainboard commit that uses it. Instead enough will need to be finished in order to be buildable, but until then things linger on Gerrit.
Please correct me if I'm way off base with that example. The stubs Patrick proposed in the other thread might help address the issue, however it can also mean adding code which exists only to satisfy the build requirement, churns as the real code changes, and may need to be removed later on anyway.
If you want to discuss trouble to get patches reviewed, please open another thread. This one is about build testing. To make it easier to work together on a big project while avoiding collisions.
You wanted some clarity on my "wild claims about consequences". The recent drama shows us that when development on coreboot.org becomes a PITA developers can just take their work elsewhere (or private). Which development model works for a particular project (or sub-project within coreboot) depends on a lot of variables and I don't think we can expect many people to stick around if we make unfeasible demands of their workflow.