Alex,
while I'm happy that you're providing hard numbers, I completely disagree with your conclusion. A much better approach, that doesn't rely on figuring out which parts happen to be inconvenient to a subset of our developers, is to build an analysis of the impact of a commit.
For global code changes, we _want_ everything to be build (and boot) tested, while a change in src/mainboard/$foo/$bar, in principle, only needs to build that single mainboard. Such an approach requires, and here comes the (somewhat) hard part, that the scope of a change can be determined reliably.
The speed-up of such an approach is close to optimal.
2015-11-01 1:36 GMT+01:00 Alex G. mr.nuke.me@gmail.com:
AGESA is a very heavy beast, at over one and a half million lines of code.
Just a note: the only reason why current Intel fares better is because they're shipping binaries that we can't even distribute in 3rdparty/blobs. Otherwise that looks pretty similar.
7 min vs 20 min on empty ccache, and 2 min vs 6 min on primed ccache. Those are speedups of 2x to 3x.
Thank you for doing the measurements.
The obvious solution is to separate AGESA into its branch.
It may be obvious to you, but there were enough good arguments brought up by a many good people that branches for such purposes aren't going to happen.
Patch trains from google and other contributions to non-AGESA code gain a 2x to 3x speedup in server time, while users of AGESA can continue to contribute and work on the codebase.
... and diverge...
Since 4.2 was just released, we can do this today without much fanare.
We have nothing to hide, so "without much fanfare" doesn't need to factor in.
To anyone saying that putting code in a branch is a death sentence,
I'm not a fan of such attempts at framing the debate.
Patrick