On 05/31/2012 09:42 AM, Jarkko Nikula wrote: > On 05/31/2012 09:31 AM, Tomi Valkeinen wrote: >> It's true that there's a commit range where the asoc stuff doesn't >> compile, and I agree that it's not good. But you need to explicitly >> enable the HDMI ASOC support to get the error. >> > You can still hit the build breakage by randconfig or if it's enabled by > default in the future and you start bisecting with that config old kernel. That's true. >>> It's quite boring to try to bisect over multiple kernel versions and >>> where most of the time goes solving random unrelated build breakages. >> >> How to get arm/arm/, omapdss, omapdrm and asoc driver changes in at the >> same time? All go through various different trees and maintainers. I >> haven't found a solution for this. If you have good ideas, please share >> =). >> > One simple - wait for next merge window. It's not that long. Only ~3 > months and meanwhile one could keep boss/customer/wife/whatever > satisfied by carrying patches in own tree :-) Well... I'm not sure how serious you are here =). In some cases that's doable, and we've done it, for example omapdrm had some things delayed until next merge window, so it's definitely an option. But it's quite easy to get some build dependencies between pull requests, so we'd be delaying features all the time. And sometimes even cross dependencies. In the worst case it could end up with delaying some features for a year to get all single pieces in bit by bit. Something I think we could try to do is create some kinds of temporary dummy functions or such which allow the compilation, but of course makes the component not (fully) functional. The temp functions could then be removed in -rc2 or so, when the dependencies are all there. But doesn't feel like an optimal solution either... Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
