On Tue, 12 Feb 2008 00:11:36 -0500 Theodore Tso <tytso@mit.edu> wrote:

quoted text
> On Mon, Feb 11, 2008 at 11:45:55PM -0500, Trond Myklebust wrote:
> > It would be very nice to have a separate tree with _only_ API changes
> > that could be frozen well before Linus' merge window opens. It should be
> > a requirement that maintainers use this tree as a basis for testing API
> > changes and even test that their own changesets were properly integrated
> > with the changed APIs.
> 
> The other way that might work in some circumstances would be if we
> tried a little harder to avoid API changes that don't involve an
> interface naming change.  That is, instead of adding a new parameter
> to a function, and then having to sweep through all of the trees to
> catch all of the users of siad function, we could instead add a new a
> new interface, __deprecate the old one, and then give enough time for
> trees to adapt, you can avoid needing to do flag day transitions.

yup, in many cases that's pretty easy to do.  But people dive straight
for the end result, which of course provides the cleanest outcome but
isn't really very real-wordly.

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.

There are lots of well-known things we can do to simplify Stephen's life. 
But first we have to have the motivation to do that thing.  If linux-next
proves to be useful and developers are seeing good testing and
bug-reporting coming out of it then I expect people will be happy to make
such accommodations.  Let's see if we can get to that stage first.


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.

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")

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/