On Mon, 11 Feb 2008 22:15:35 -0800 Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > Another thing we could do when these things happen is all gang up on Linus > and ask him to merge the API change into mainline. Because often the > change can be done in two stages: 1) change the interface then 2) add the code > in the callee which _uses_ that changed interface. Part 1 is an obviously-safe > do-nothing change and fixes the merge problems. Part 2 is at a single site > and can be merged in 2.6.x+1. I have an alternative (with help from Paul Mackerras). We have a branch in linux-next that is stable and only progresses forward i.e. is never rebased. Global API changes/introductions that are of type 1 above go into this branch (after appropriate etc). Fixes to them go in as well. People can base development on this branch. But ... they can only really do that *if* we can guarantee that part of linux-next will be in Linus' tree very early in the next merge window. So here is the had part ... We need to ask Linus to promise that he will pull the stable branch from linux-next first in the merge window. For that to happen, I would expect that Linus would also review and sign off (or ack) these commits to the linux-next tree. The rest of linux-next would always be based on the stable part plus Linus' current tree. Will this fly? Comments? > A fully running and successful linux-next won't change outcomes a lot, I > expect. It will help to pick up on obvious bugs and build errors and > bisection breakages prior to them hitting mainline. But we fix those > things by -rc1 or -rc2 anyway. So it's just a time-shift, causing no great > change in the final 2.6.x. I am hoping that this time shift will allow more time for bug fixing/polishing. But maybe I am being to optimistic again :-) > linux-next will do little to solve our (IMO) largest problem: unfixed > regressions and bugs. otoh it will free up a lot of my time and > hair-tearing, so I can devote more attention to the bugs. (where > "attention" usually= "sending irritiating emails") And may be you can get more sleep and dream up some more schemes :-) -- Cheers, Stephen Rothwell sfr@xxxxxxxxxxxxxxxx http://www.canb.auug.org.au/~sfr/
Attachment:
pgp6ItfzLsKCZ.pgp
Description: PGP signature
