On Mon, 11 Feb 2008 22:15:35 -0800 Andrew Morton <akpm@linux-foundation.org=
quoted text
> 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
quoted text
> in the callee which _uses_ that changed interface.  Part 1 is an obviousl=
y-safe
quoted text
> do-nothing change and fixes the merge problems.  Part 2 is at a single si=
te
quoted text
> 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?

quoted text
> 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 gre=
at
quoted text
> 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 :-)

quoted text
> 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=3D "sending irritiating emails")

And may be you can get more sleep and dream up some more schemes :-)
--=20
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/