When working on collateral evolutions often times by definition we end up having to go and transform existing drivers to new APIs tree wide. You have a few options when this happens:
0) *If* you're lucky your collateral evolution is very specific to a subsystem and you get to only work with one maintainer. Otherwise: 1) You get approval from a subsystem maintainer for their respective driver changes to go in through the tree you are introducing the new symbols you are adding or symbols you are changing. 2) You sit tight and wait for the symbols to go in through one release, and on the next next release you submit the changes for the drivers. 3) You wait towards the end of the merge window and finally send directly to a subsystem maintainer, who then sends to Linus. As noted, 0) is a breeze and is pretty straight forward. The problem with 1) is you need coordination with maintainers and while this can be a smooth process it typically is more an irritation for the maintainers involved, its more work on other maintainers, and you should not be surprised if some folks get irritated. Understandably there can be a limit to what one maintainer should accept to go in through their tree just for cross-tree collateral evolution effects. The problem with 2) is the obvious lag behind making your changes take effect through 2 full releases, as per our latest stats [0] we get a release every 2.5 months, so on average cross-tree collateral evolutions with strategy 2) means you'd have to wait ~5 months in order to see your changes in the wild, with a reasonable added *minimum* delay of say... about 1 month for review that's realistically more like a full half year to wait. That's a lot of time... that's pretty slow. 3) still requires going through a subsystem maintainer, that seems rather slow, specially if the patches are already acked and all you were doing was waiting for the merge window. That can only delay the merge window a bit. I think we can do better and I think we can do with this much less irratation for maintainers. What if we had a linux-oven tree based on linux-next which queues up all pending-but-already-acked cross-tree collateral evolution patches? This tree can be rebased daily on linux-next using: git rebase --onto next/master' for example, and this maintainer can then send these cross-tree collateral evolution changes to Linus towards the end of the merge window. Thoughts? [0] http://phb-crystal-ball.org/ Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/
