On Fri, 5 Mar 2010, David Miller wrote: > > In fact, I argue that the moment nouveau went into Fedora and > was turned on by default, the interfaces needed to be frozen.
Now, I agree that that would have been the optimal setup from a testing an user standpoint, but I think it's a bit too strong. Things don't need to be "frozen", but flag-days need to be avoided. The problem with flag-days is not so much that they need new support code: downloading a new version of something like X is not a huge issue. But flag-days work both ways: it's not just that you have to download a new version, it's that you can't go _back_ either - not even a little bit. For example, I can now test my new kernel, but if it turns out that there are problems with it, I'm now officially screwed. I can't go back and rely on even the stable distro kernel, like I'm used to ("ok, that _really_ didn't work, but happily I didn't remove the distro kernel, so I'll just reboot with that"). And I certainly can't bisect without major problems. And Fedora can't install the new libraries, because they won't work with their own old kernels either. So it effectively causes a version freeze: it looks like F12 will simply _never_ be able to support a 2.6.34 kernel, because if they do that, then everybody who gets the new packages (and has a nvidia graphics card) will now be stuck. So flag-days really are bad. They're bad for users, they're bad for distributions, and they're eventually bad for developers too because now they lose a lot of every-day testing. Some day, F13 will come out, and the _only_ testing all the new code ever got was the (relatively small) rawhide community, and the kernel crazies who did things manually. But even if you can't guarantee backwards compatibility, if you avoid the flag-day, and can have a new version of the environment that can handle both the old and the new model, you _could_ install that on F12 (before switching kernels), and not be in that effective version-freeze. Yeah, you'll still have a dependency chain, but it will be a one-way one, so you're not stuck. As long as you have the newest vesion of whatever libraries or support, you can go back-and-forth and test development systems. And we do that for the kernel in many other respects. We require that you have a "recent enough" compiler, for example. So there are already lots of those one-way dependencies where we're not infinitely backwards compatible with user space, but we've been pretty good at not having flag-days. Linus ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel