2010/9/29 Arnd Bergmann <a...@arndb.de>: > [Me] >> Any hints on how to get out of this and create a simple >> git tree or set of trees is welcome, I have yet not found >> any. > > I think you need to stop basing on top of linux-next and > move to basing on top of the smallest possible set of trees > other than mainline.
Right now we have dependencies on this forest: - partitions - doesn't have git tree - ARM - input - SPI - I2C - GPIO - MTD - MFD - async_tx (DMA) - Andrews patch stack > Today's series seems to apply almost cleanly on top of > Russell's ARM tree, so as a start, you can create one git > tree based on his and apply all your patches on top. Maybe, the 9 other repos more or less depend on their platform data going into the ARM tree. > Since the base also in linaro-next, Nicolas can easily merge > it. If you have dependencies on other trees, say the MMC > tree, then split out the MMC related patches into a > separate series and apply them on the mmc-next tree, > and put them into a different branch in your git. The MMC tree does not exist, the MMC patches are maintained in Mortons patch stack. We have also had to shovel all our backlight and LED patches into that patch stack in Purdies absence. But I've seen Mortons stack being used as a pseudo-tree in -next so must be possible to bring that in anyway. The big hit from using Nicolas tree will rather be that it is 2.6.35-based, while we have a lot of stuff merged for 2.6.36 and a similar pile of stuff stacked in different next trees so I will have to pull all of that out (including some extensions to frameworks we made along the way) in order to get something in shape for a 2.6.35 branch. But it can probably be done. > Create a master branch in your git than merges all the > separate branches for people to test out your code. Yeah I understand that part atleast, it looks like I'll spindle up something like 9 topic branches per subsystem and bring that into a master branch with an octopus merge, it's more or less what the current patch stack does but with a number of topic branches. Do you usually split the ARM platform data per-subsystem or do you stack that up in the ARM branch and bring that on top of the others? Right now we have a lot of collisions in ARM due to a lot of platform data patches, we've tried to limit it by splitting the platform files a bit, but it's still a bit of churn... > Things get a bit hairy if the tree you base on gets > rebased. Most maintainers do this very rarely, so you > should be fairly safe. That's not going to be a big problem I think. The upside of just using a smaller stack on top of next is that once the patches are in respective subsystem next branch I don't have to worry about them anymore. The proposal here is probably more along the lines of satisfying the Linaro needs of keeping a (currently) 2.6.35-based tree with all members stuff on top. It seems like pretty much a full time integration effort if it is to be maintained so I'll need to be assigned to do it first I believe, I still need to get my official Linaro assignment, you never know, maybe I will be assigned to clean the coffee machine in Taipei instead ;-) Yours, Linus Walleij _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
