* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, 14 Feb 2008, Stephen Rothwell wrote: > > > > Originally, I assumed the stable branch would be for our "usual" API > > changes, but it appears we are not having any more of those. :-) > > It's not that we should _never_ have them, it's that they shouldn't be > "business as usual". > > I'm happy with them being a "a couple of times a year". I'm not happy > with them being "once or twice for every release cycle". That's the > big deal for me. 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 - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
