Cc: Jeff Garzik <jeff@...>, David Miller <davem@...>, <arjan@...>, <greg@...>, <sfr@...>, <linux-kernel@...>, <linux-next@...>, <linux-arch@...>, <akpm@...>
.. btw: I'd need to know this in advance. I usually don't see the problem
until it's too late.
And this is very much an area where "Linux-next" can help: if some
subsystem causes problems in Linux-next for other maintainers, I really
think it shouldn't just be a matter of "drop the git tree that didn't
merge cleanly", but it should literally be a question of "maybe we should
drop the _earlier_ git tree that caused the later one not to merge
cleanly".
In other words, maybe things like core block layer changes or device model
changes should be *last* in the merge-list (or if first, also be first to
be dropped if they cause merge errors downstream!).
That way, infrastructure changes that screw up others can only happen if
the maintainer actively works with the others to make sure it works even
before it would ever merge into Linux-next successfully.
That may sound odd, but it actually matches what I personally believe in:
we have more driver code and other "outlying" things than we have core
things, and most of our problems come from that - so we should prioritize
*those* things, not the "fundmantal core changes".
So how about making that the default situation: drivers and other outliers
merge first. If fundamental API changes happen, they merge last, and if
their maintainers can't make it in time in the merge window, they just get
dropped.
That sure as hell would put the pain on API changes solidly where it
belongs.
Linus
--
