Patch Merging Path - RMK or Arnd?

Patch Merging Path - RMK or Arnd?

[Will Deacon]

Hi Arnd,

In general, I merge my patches via Russell as they tend to be core ARM changes.
This works very well since other (potentially conflicting) changes follow
the same route and any conflicts would be noticed almost immediately.

However, I currently have two patchsets that I'm developing which alter both
core ARM code *and* touch a number of platforms to use the new core
features:

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/061304.html

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-August/061477.html

Ideally, I would also merge these via Russell, but there is now scope for
conflict with your arm-soc branch given that I'm changing files under mach-*
and plat-*. How would you recommend that I proceed? I can think of three
solutions:


(1) [preferred] Merge via Russell, conflicts show up in -next and are
    resolved then.

(2) Split the patches up so that the core changes go via Russell. When they
    are in a suitable tree (-next?) then send you the remainder on top of
    that.

(3) Merge the whole lot via you. This really just inverts the problem rather
    than solving anything.


I expect this will become a fairly common pattern with single zImage work,
so it would be great to clarify the intended path upstream.

Cheers,

Will

Patch Merging Path - RMK or Arnd?

[Arnd Bergmann]

On Friday 19 August 2011, Will Deacon wrote:
> Ideally, I would also merge these via Russell, but there is now scope for
> conflict with your arm-soc branch given that I'm changing files under mach-*
> and plat-*. How would you recommend that I proceed? I can think of three
> solutions:
> 
> 
> (1) [preferred] Merge via Russell, conflicts show up in -next and are
>     resolved then.
> 
> (2) Split the patches up so that the core changes go via Russell. When they
>     are in a suitable tree (-next?) then send you the remainder on top of
>     that.
> 
> (3) Merge the whole lot via you. This really just inverts the problem rather
>     than solving anything.
> 
> 
> I expect this will become a fairly common pattern with single zImage work,
> so it would be great to clarify the intended path upstream.

There is another options, which is to have the changes in both trees, or
at least have some of the changes in both.

Fortunately, git can handle merges of that sort just fine, so I'd say
depending on the contents you do one of:

(4) Split up the changesets into a core set (for the arch directory) and
    a second set that goes on top and changes all the platforms. Get
    Russell to take the base patches into one branch, and submit the
    branch containing the full set (including the ones in Russell's
    tree) for the arm-soc tree. I will then make sure queue the changes
    for merging to Linus after he has taken the base changes from
    Russell.

(5) Prepare one git tree and submit it to both trees at once. If everyone
    is happy with the changes, we just apply it to both and one of us
    submits it first.
    Either tree can also contain further changes on top, so if your
    changes are already upstream through one tree, the second pull request
    from the other tree will contain the other changes that go on top.

This is really not much different to dependencies on any other tree,
e.g. when the gpio subsystem has some changes that are required for
platform specific changes that go through the arm-soc tree.

	Arnd

Patch Merging Path - RMK or Arnd?

[Will Deacon]

Hi Arnd,

Thanks for the reply.

On Fri, Aug 19, 2011 at 03:21:56PM +0100, Arnd Bergmann wrote:
> On Friday 19 August 2011, Will Deacon wrote:
> > Ideally, I would also merge these via Russell, but there is now scope for
> > conflict with your arm-soc branch given that I'm changing files under mach-*
> > and plat-*. How would you recommend that I proceed? I can think of three
> > solutions:
> > 
> > 
> > (1) [preferred] Merge via Russell, conflicts show up in -next and are
> >     resolved then.
> > 
> > (2) Split the patches up so that the core changes go via Russell. When they
> >     are in a suitable tree (-next?) then send you the remainder on top of
> >     that.
> > 
> > (3) Merge the whole lot via you. This really just inverts the problem rather
> >     than solving anything.
> > 
> > 
> > I expect this will become a fairly common pattern with single zImage work,
> > so it would be great to clarify the intended path upstream.
> 
> There is another options, which is to have the changes in both trees, or
> at least have some of the changes in both.

Ok, I hadn't considered that.

> Fortunately, git can handle merges of that sort just fine, so I'd say
> depending on the contents you do one of:
> 
> (4) Split up the changesets into a core set (for the arch directory) and
>     a second set that goes on top and changes all the platforms. Get
>     Russell to take the base patches into one branch, and submit the
>     branch containing the full set (including the ones in Russell's
>     tree) for the arm-soc tree. I will then make sure queue the changes
>     for merging to Linus after he has taken the base changes from
>     Russell.
> 
> (5) Prepare one git tree and submit it to both trees at once. If everyone
>     is happy with the changes, we just apply it to both and one of us
>     submits it first.
>     Either tree can also contain further changes on top, so if your
>     changes are already upstream through one tree, the second pull request
>     from the other tree will contain the other changes that go on top.

That's (5) probably easiest, because then you can be sure that the patches
in each upstream tree are identical.

Russell - would you be happy with this arrangment for patchsets that touch
platforms and core ARM code?

Will

Patch Merging Path - RMK or Arnd?

[Arnd Bergmann]

On Friday 19 August 2011 15:45:51 Will Deacon wrote:
> > Fortunately, git can handle merges of that sort just fine, so I'd say
> > depending on the contents you do one of:
> > 
> > (4) Split up the changesets into a core set (for the arch directory) and
> >     a second set that goes on top and changes all the platforms. Get
> >     Russell to take the base patches into one branch, and submit the
> >     branch containing the full set (including the ones in Russell's
> >     tree) for the arm-soc tree. I will then make sure queue the changes
> >     for merging to Linus after he has taken the base changes from
> >     Russell.
> > 
> > (5) Prepare one git tree and submit it to both trees at once. If everyone
> >     is happy with the changes, we just apply it to both and one of us
> >     submits it first.
> >     Either tree can also contain further changes on top, so if your
> >     changes are already upstream through one tree, the second pull request
> >     from the other tree will contain the other changes that go on top.
> 
> That's (5) probably easiest, because then you can be sure that the patches
> in each upstream tree are identical.

That's the idea with (4) as well. The difference there is that one of the
two trees only contains a subset of the patches, but those are using the
same commit IDs. The other tree has the remaining changes on top of the
common ones.

	Arnd

Patch Merging Path - RMK or Arnd?

[Will Deacon]

On Sat, Aug 20, 2011 at 10:23:22PM +0100, Arnd Bergmann wrote:
> On Friday 19 August 2011 15:45:51 Will Deacon wrote:
> > > Fortunately, git can handle merges of that sort just fine, so I'd say
> > > depending on the contents you do one of:
> > > 
> > > (4) Split up the changesets into a core set (for the arch directory) and
> > >     a second set that goes on top and changes all the platforms. Get
> > >     Russell to take the base patches into one branch, and submit the
> > >     branch containing the full set (including the ones in Russell's
> > >     tree) for the arm-soc tree. I will then make sure queue the changes
> > >     for merging to Linus after he has taken the base changes from
> > >     Russell.
> > > 
> > > (5) Prepare one git tree and submit it to both trees at once. If everyone
> > >     is happy with the changes, we just apply it to both and one of us
> > >     submits it first.
> > >     Either tree can also contain further changes on top, so if your
> > >     changes are already upstream through one tree, the second pull request
> > >     from the other tree will contain the other changes that go on top.
> > 
> > That's (5) probably easiest, because then you can be sure that the patches
> > in each upstream tree are identical.
> 
> That's the idea with (4) as well. The difference there is that one of the
> two trees only contains a subset of the patches, but those are using the
> same commit IDs. The other tree has the remaining changes on top of the
> common ones.

Thinking about this a bit more, (4) can also avoid the situation where one
tree pulls the series but the other tree has reservations about the code and
decides not to take the patches. So, in my case, I could get the core
changes merged by Russell and then send you the full set afterwards.

Will

Patch Merging Path - RMK or Arnd?

[Russell King - ARM Linux]

On Sun, Aug 21, 2011 at 12:29:40PM +0100, Will Deacon wrote:
> Thinking about this a bit more, (4) can also avoid the situation where one
> tree pulls the series but the other tree has reservations about the code and
> decides not to take the patches. So, in my case, I could get the core
> changes merged by Russell and then send you the full set afterwards.

I think (4) is the sensible one too.