Jean Delvare writes:
I sympathize, but throwing disruptive changes into Linus' tree when we're past -rc3 is not the way to solve the problem.
We're past -rc3 because people discuss instead of testing my patches. Otherwise everything would be merged already.
Well, no. The first conversion patch that I saw was posted after the merge window had already closed, on 8 April.
And really, these changes (sound drivers) don't qualify as disruptive. You might argue about the thermal management driver changes if you want. But sound drivers, nothing bad will happen if they accidentally break.
That's what we call a "regression". :)
But linux-next will only build-test the code. That I have already done, so it really doesn't buy my anything. Developers (including me) don't look at warnings in linux-next, and I don't think linux-next gets a lot of testing.
If you remove the legacy interfaces then even a build test will point out the drivers that still need to be converted. :)
Also, I can't push all untested patches to linux-next. In particular the 4 patches that touch thermal management on powermac, need to be tested successfully by at least one person before I can push them. You did test the therm_pm72 patch, and I thank you for that, so that one is in linux-next, but the other 3 ones need testing.
So, really, you're trying to solve the wrong problem. Whether the patches go to Linus now or in the next merge window, doesn't really matter.
It does matter, actually.
And 2.6.31 isn't the kernel to remove an interface which was scheduled for removal in 2.6.29 and then 2.6.30 and which is blocking the development of features people need badly.
What's so special about 2.6.30 that it matters whether the legacy interfaces are still there or not?
As for blocking development, you can remove the legacy interfaces today in your next branch and get on with development immediately. So the "blocking development" argument has zero relevance to what goes into Linus' tree for 2.6.30. Even if you got the legacy interfaces removed for 2.6.30 you still wouldn't be able to get any new features based on that into 2.6.30.
And this is a particularly bad time to be hastily trying to get powermac driver changes upstream, since Ben H. is on vacation.
So, once again, can powermac developers/users please test my patches?
Can we compromise on this? I'll do everything I reasonably can to help you get the powermac driver patches tested and working before the 2.6.31 merge window, if you agree to leave the drivers and interfaces in Linus' tree as they are for 2.6.30.
Paul.