Stephen Rothwell wrote: > On Thu, 14 Feb 2008 10:01:14 -0800 (PST) Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> 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. > > So, will you open such a branch? If so, what would be the mechanics of > having patches applied to it? I assume people would have to suggest such > changes explicitly and have them reviewed (hopefully more thoroughly than > usual) in that light. I guess one place these "infrastructure" changes > may be noticed would be when subsystem maintainers stray outside their > subsystem in what they submit to the linux-next tree (or break it). Two things may largely eliminate the need for parallel branches. 1. Do infrastructure changes and whole tree wide refactoring etc. in a compatible manner with a brief but nonzero transition period. 2. Insert a second merge window right after the usual merge window for changes which cannot be well done with a transition period. (I probably missed a number of points why these two things are not always feasible, because I am just a downstream person.) -- Stefan Richter -=====-==--- --=- =-=-- http://arcgraph.de/sr/ - 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
