On 05/31/2012 10:00 AM, Tomi Valkeinen wrote: >> 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 =). > Quite serious :-) > 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 what is usually done is to get ack from maintainers and let code to be merged via another tree. Needs careful planning though in order to avoid preventing e.g. API changes in one subsystem. > 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... > Yeah, this might work too. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
