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. If we have a big flag-day that affects a lot of drivers (or architectures) once or twice a year, I think everybody involved will be happy to stand up and say "ok, that fixes problem X, and the new thing really is better, so let's do it, it's worth it". But if it's something that happens essentially every single release, that is somethign else altogether. Then it's not a "ok, let's bite the bullet and make the kernel better" thing any more, but instead it devolves into "f*ck, the merge window is open again, now I have to fix up all the crap people pushed on me". See? That's a *huge* difference, even if it is "only" a mental one (and clearly it isn't - there's the actual real work of the "I have to fix things up" part too). So to recap: I have absolutely nothing against fixing up bad internal API's and breaking things. But 99% of the time that should be something we can do incrementally (ie introduce the new API, and simply accept the fact that removing the old API will take a few months). And the case when that _really_ doesn't work should be rare enough that it doesn't wear people down. Because if you listen to the tone of people in this discussion, much of it is about people being _tired_ of having to fix things up. It's not exactly been a "wow, the end result sure was nice!" kind of discussion, is it? And this is where "process" really matters. Making sure people don't get too frustrated about the constant grind. > However, > I see an argument for attempting to stabilise possible conflicting > changes get Linus' review/ack and add them to the stable branch. > > Linus suggested that such changes should go into an independent tree that > everyone could pull into their trees with the full confidence that that > tree would be merged into Linus' tree when the merge window opens. I am > suggesting that that tree be the stable branch of linux-next. I absolutely have no problem with having a "this is the infrastrcture changes that will go into the next release". In fact, I can even *maintain* such a branch. I've not wanted to open up a second branch for "this is for next release", because quite frankly, one of the other problems we have is that people already spend way too much time on the next release compared to just looking at regressions in the current one. But especially if we're talking about _purely_ API changes etc infrastructure, I could certainly do a "next" branch. Linus - 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