On Wednesday 29 September 2010, Linus Walleij wrote:
> 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
Ok, I see. That's roughly the same list I had come up with when
I looked at yesterday's series of patches.
However, I guess for most of these, you don't have *both* patches
merged to the subsystem tree and unmerged patches on top, right?
The easy cases are those where you have a series of patches
for one subsystem and they all get merged at once.
Just create one branch that contains your patches if they
are not merged and ask the maintainer to pull them. Before they
are merged, your own branch then has no dependencies on the
main one. After they are merged, you can pull the maintainer
tree into your own branch.
If linaro-next contains the subsystem tree and your branch,
and they contain identical commits (because one of them got
pulled into the other), the merge will be trivial.
> > 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.
This is just a dependency for being able to use it, right?
AFAICT nothing should break if you have just the subsystem
changes or just the architecture changes, and in order
to use the new code you just need to pull both branches.
> > 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.
No, it actually works the other way round. Andrew bases his
quilt on top of -next.
linux-next contains an mmc tree pulled from
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git#mmc-next
You should try to get Chris Ball to take all the patches that
are currently in Andrew's -mm tree. This is how Andrew normally
expects things to flow when there is a maintainer.
> 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.
Remember you should not "use" Nicolas' tree, you should feed
into it. As he already explained, there are two trees,
so you need to decide if you want to have stuff in both of
them or just the one following mainline.
> > 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.
Right.
> 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...
I've seen both done before. It generally depends how
hard the octopus merge gets. If it's just different branches
adding new code to the same place, the merge is not that
hard and you can try to keep the platform data together
with the drivers.
> > 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.
No, don't worry about the 2.6.35 tree too much. The first priority
is to help you get your stuff upstream, the second priority
is to increase the amount of testing before it gets there.
Arnd
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
