If that API change doesn't conflict with the work that hundreds of other
people do, it's obviously not a problem whichever way it goes.
And if the API change *does* cause conflicts, then yes, the onus of fixing
those conflicts (again) goes to the person who changed the API. Everybody
else did everything right.
You think that infrastructure is more important than outlying code. But
you do that only because you write the infrastructure, not because you
have any logical reason to think so.
The fact is, that "outlying code" is where we have all the bulk of the
code, and it's also where we have all those developers who aren't on the
"inside track". So we should help the outliers, not the core code.
And very fundamentally, API changes are to be discouraged. If we make them
harder to do and make people think twice (and occasionally say "not worth
it"), that sounds like a damn good thing to me.
Linus
--
