Re: [PATCHv4 0/9] *** ARM: Update arch-vt8500 to Devicetree ***

[Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>]

On Thursday 23 August 2012, Tony Prisk wrote:
> >On Thursday 23 August 2012, Tony Prisk wrote:

> 
> Without the clock patch (9/9), the mach-vt8500 patch (6/9) won't compile
> due to unresolved symbols.
> 
> In arch/arm/mach-vt8500/vt8500.c - you will get an unresolved symbol
> for 'vtwm_clk_init'
> 
> Not sure if this matters, thought I should point it out.
> Does it need to compile cleanly in your tree (which is what I would assume),
> or just once its all combined in -next?
> Does it matter that the usb patches are already in -next?
> 
> I don't really understand the requirements around submitting to individual
> trees and which (if any) of these points are actually issues.

The rule is that each changeset should be free of regressions compared
to the version before. So if you have a set of 7 patches in one branch
that you want me to pick up, the result after applying those 7 patches
should work, and each previous step should also work. You cannot for
instance add a call to a function in one patch and then provide that
function in the following patch.

There are multiple ways to achieve this:

* when you have dependencies, get everything merged through one
maintainer tree, and get Acks for each patch that belongs to another
maintainer.

* submit a branch with the patches that other stuff depends on to
both the subsystem maintainer who is responsible for it and to
the subsystem maintainer who gets the other patches that are built
on top of this branch. If you do this, you have to make sure that
the first branch never gets rebased and that the second branch is
not sent before the first one is upstream.

* change the code so that no dependencies exist, e.g. by introducing
a dummy implementation in one patch and the proper one in another.
This can generate merge conflicts, but that's usually ok.

	Arnd