very much agreed. I've yet to see a _single_ wide-scale API change that
broke stuff left and right where that breakage was technically
justified. I have not seen a single one.
All those cases were just plain old botched attempts. Either someone can
do a large-scale API change like the irq_regs() cleanups with near-zero
breakages, or someone cannot. In the latter case, gradual introduction
and trickling it through subsystem trees is a _must_.
and if it's _hard_ to do a particular large-scale change, then i think
the right answer is to _not do it_ in a large-scale way, but do it
gradually.
I claim that there's just not a single valid case of doing wide-scale
changes atomically and departing from the current to-be-stabilized
kernel tree materially. _Every_ large-scale API change can be done in a
staged way, with each subsystem adopting to the change at their own
pace, it just has to be planned well and tested well enough and has to
be executed persistently. And the moment we trickle things through
subsystem trees, there's no integration pain, as subsystem trees are
largely disjunct anyway.
i also fear that having an API-changes-only tree will dillute our
testing effort of the current to-be-stabilized upstream tree, as it
materially disrupts the flow of patches. Most maintainers should
concentrate on stabilizing current -git with only one serial queue of
fixes and enhancements ontop of that tree. I dont see how having a
second queue would help - it clearly splits attention.
widescale API changes should be discouraged, and forcing them through
the harder, "gradual, per subsystem" route is _exactly_ such a strong
force that discourages people from doing them.
Ingo
--
