Hi Paul,
On Wed, 22 Apr 2009 22:56:52 +1000, Paul Mackerras wrote:
Jean Delvare writes:
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.
I had the hope that the developers/maintainers involved would not ignore the warnings and had patches ready, that would go to Linus during the merge window. This didn't happen, call me naive if you want. So right after rc1 I started working on the conversion myself.
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". :)
Regressions happen all the time, no matter how hard we all try to avoid them. As long as they are fixed before -final, this isn't a big problem though.
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. :)
I don't consider breaking the linux-next build a good practice, sorry. I suspect this tree doesn't get a lot of testing, breaking it isn't going to improve the situation. Not to mention that this will make Stephen's life harder, which isn't my goal. I do have a list of drivers that aren't yet converted upstream, I don't need linux-next to tell me. Except for new drivers, of course, there I agree your strategy has value (but has a flaw, see below.)
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?
3 months ago, people told me "what's so special about 2.6.29". The result is that we made very little progress and the legacy interface was still used by 10 (non-staging) drivers in 2.6.30-rc1. There's nothing special about 2.6.30 other than the fact that I am fed up waiting for all drivers to drop using a deprecated API so that I can remove it. Again, further i2c developments are blocked by the existence of this deprecated API.
As for blocking development, you can remove the legacy interfaces today in your next branch and get on with development immediately.
No, I can't, that would break the linux-next build, as explained above. I would also have to include all the driver conversion patches there. The problem is that this still touches drivers/macintosh, drivers/media/video and sound/ppc at the moment, each of which is supposed to be maintained in a different tree. If I include these patches in my i2c tree, chances of collisions with other trees are big, which means more work for Stephen. If the patches are instead included in their respective trees (as Takashi just did for sound/ppc), you avoid the collisions, but then I can't remove the legacy API in linux-next, because the i2c tree is listed relatively early, so bisecting (or just incrementally building) linux-next would fail horribly.
So, as you can see, the problem you think is so easily solved by linux-next, isn't. The only thing I can do at this point is keep the patches in a local tree and point other interested developers thereto. Basically I'll tell them "you need to use linux-next plus a number of public patches that can't go to linux-next plus the development patches we are discussing." This makes the work and discussions about further developments much more difficult, and results in zero testing outside the development group, which makes it unclear if they will be ready for 2.6.31.
Compare this with the case where all driver conversions are already in Linus' tree (even without removing the legacy interface): I can put the legacy interface removal and all the development patches in linux-next and interested people can test just this, and this is build tested on several architectures, and possibly even runtime-tested by a few random users. This is way less work for everyone and a much better quality in the end.
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.
But I would be able to get the new features in 2.6.31. With your plan, I doubt this can happen.
And this is a particularly bad time to be hastily trying to get powermac driver changes upstream, since Ben H. is on vacation.
Yes, that I admit is pretty bad luck :(
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.
"Before the 2.6.31 merge window" is way too late if I want any i2c development to make it into 2.6.31 as well. The conversions must go in linux-next as soon as possible. Even that isn't ideal as I explained above, but that's the bare minimum to make sure everything (driver conversions, interface removal and i2c developments) has a chance to be ready for 2.6.31.
Note that I did get some more test results meanwhile. Johannes Berg was able to test the windfarm drivers conversion, and Andreas Schwab tested the therm_adt746x conversion, both successfully. So the only two drivers which didn't get any testing at this point are keywest (snd-powermac) and therm_windtunnel. That being said, more testing for every driver is certainly welcome. You can check the current status at: http://i2c.wiki.kernel.org/index.php/Legacy_drivers_to_be_converted
I agree to stop pushing driver conversions to Linus for 2.6.30, which means the legacy API will stay there. Some drivers have already been converted though (go7007 in rc3) and some conversions are scheduled to go to Linus already (sound drivers in rc4, Takashi said.) This means 7 remaining unconverted drivers in 2.6.30 (6 powermac thermal management drivers, and ir-kbd-i2c.)