Re: [git pull] drm request 3

[Linus Torvalds]

On Fri, 5 Mar 2010, Dave Airlie wrote:
> 
> Speaking as distro maintainer here,
> 
> No because we've got versioned interfaces and we are happy to support them
> yes it would be nice sometimes to dream about this, but its a major explosion in
> the testing matrix. You have to realise the more codepaths a distro ships, the
> more codepath it has to keep track off for security issues, for bug fixes, etc.

I think you're missing the whole point here. There's no new and complex 
"testing matrix". You only ever test the newest version, so there's no 
additional testing.

Here's the "inductive proof":

 - if the version number doesn't change, you aren't doing anything that is 
   at all different from what you already do.

 - if the version number _does_ change, it does so only because you 
   updated both the kernel component and the libdrm component together, 
   and you test them together - exactly like you already do.

So there is absolutely no difference for you. In either case, you only 
ever test paired up versions. If you make a new version, it will never 
_ever_ interact with old versions. There's no new complex testing needed.

The only thing it allows is for you to have multiple kernels installed 
simultaneously - and be able to _use_ them all. Which is something you 
already do.

And which the current model doesn't allow for. You may have three 
different kernels installed, but if libdrm got updated with a version 
change, only one of those kernels will actually _work_.

> When to we decide to stop shipping nouveau_drv-0.0.13? when do we find
> out it has a security issue?

Irrelevant and total red herring. You never care about older versions, 
since if people have updated, they are running the newer version.

So the older versions are there purely so that you _can_ have multiple 
different kernels, and so that your _developers_ can compile new kernels 
for older distributions. They aren't relevant for the case you point to: 
if somebody is just doing "yum update", they'll get - and use - the newer 
version anyway.

> Here's the thing, distros are trying to ship an OS with a consistent set 
> of packages, not a pick-n-mix.

But here's the thing: if you expect people to do development, they _need_ 
to be able to mix things. A kernel developer needs to be able to update 
their kernel. And a kernel _tester_ needs to be able to test that kernel.

Seriously: what do you expect me to do right now in my situation?

I'm not going to release a kernel that I can't test. So if I can't get a 
libdrm that works in my F12 environment, I will _have_ to revert that 
patch that you asked me to merge.

Really. Look at it from my standpoint. Look at it from _any_ kernel 
developer standpoint. It would be totally irresponsible of me to release 
2.6.34 without even eating my own dog-food on my own main machine. Can't 
you see that this is obviously true?

So right now, I'm running with that patch reverted on that machine. I 
haven't committed the revert, and quite frankly, I'd really prefer not to. 
But the only way that "not revert" case can really happen is if there is 
some other way for me to have a working machine again.

Think about it. Tell me what the solution is.

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