Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]

Hi Tony,

On Fri, 15 Apr 2016 08:41:40 -0700
Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:

> * Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> [160415 04:52]:
> > Roger, Tony,
> > 
> > On Fri, 15 Apr 2016 13:54:34 +0300
> > Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > 
> > > On 15/04/16 13:09, Boris Brezillon wrote:
> > > > Hi Roger,
> > > > 
> > > > On Fri, 15 Apr 2016 12:34:04 +0300
> > > > Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> wrote:
> > > > 
> > > >> Tony & Boris,
> > > >>
> > > >> On 14/04/16 00:25, Tony Lindgren wrote:
> > > >>> * Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org> [160407 03:10]:
> > > >>>> Hi,
> > > >>>>
> > > >>>> As this series has cross dependency between omap and mtd subsystems,
> > > >>>> I'll set up a immutable branch which omap-soc and l2-mtd must
> > > >>>> merge in together to avoid any conflicts/breakage during integration.
> > > >>>>
> > > >>>> Brian has acked all mtd patches. Tony needs to give his Ack for the
> > > >>>> gpmc driver part and then I can provide the immutable branch.
> > > >>>
> > > >>> Looks good to me, please feel free to add:
> > > >>>
> > > >>> Acked-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > > >>>
> > > >>
> > > >> I've added Tony and Rob's Acked-by tags and pushed the patches at the
> > > >> below PULL request.
> > > >>
> > > >> Please take this into omap-soc and l2-mtd trees. Thanks.
> > > > 
> > > > I Pulled this branch into nand/next and had to resolve a few conflicts
> > > > (as you may have noticed, a few other reworks in the NAND and MTD layer
> > > > have been merged in the meantime).
> > > 
> > > OK. I'm not sure how well this will play when this merges into liunx-next
> > > via the omap-soc tree.
> > > 
> > > Instead, can you please create a non-mutable nand/base for me (which could be
> > > today's nand/next) and I can base my branch on that and Tony can use my
> > > branch without causing any merge-conflict in linux-next?
> > 
> > I just created a branch called nand/for-gpmc-rework based on today's
> > nand/next, but I'm still unsure how to proceed once you've rebased your
> > work on this branch?
> > 
> > Tony will first have to pull my immutable branch, then pull yours, and
> > then I'll have to pull an immutable branch from the the omap-soc tree
> > to get your changes into my nand/next branch (in case other patches
> > modify the same files before I send my PR). Am I missing something?
> > If I'm not, then this option looks over-complicated to me.
> 
> Well why don't you merge it all via NAND then? I'm not seeing
> any merge conflicts with the arch/arm/mach-omap* code.

I'm perfectly fine with that. Actually, that's what I first did (see the
nand/next-with-gpmc-rework I asked Roger to validate).
Roger, since you don't have any dependencies on omap stuff added after
4.6-rc1, I could even rebase your patches on top of nand/next to avoid
this merge commit (and the associated conflict resolution).

> 
> > ITOH, if we decide to let your patches go through the nand or omap-soc
> > tree, only one immutable branch will be created, and either the nand or
> > omap-soc maintainer (depending on who takes the patches) will have to
> > pull it into its -next branch.
> > 
> > I'm quite new to all this merging process, so don't hesitate to correct
> > me if I'm wrong.
> 
> Well the rules are that if something agreed to be immutable, then
> it will never get redone. And the immutable branch should be based
> on the absolute minimal set of patches against some earlier tag,
> usually -rc1 is a good one. This avoids other tree to need to pull
> in a huge amount of changes from other trees just to avoid merge
> conflicts.

How would you do it in this particular case. Say I have to provide you
with an immutable branch, it should only contain Roger's patches, right?

But this also means this immutable branch has to be pulled into my
nand/next branch before all other changes touching the same set of
files, which in turn means that I'll have to rebase and push -f my
nand/next branch (which I'd like to avoid).
Or should I just pull this immutable branch in my current nand/next and
let you pull the same immutable branch in omap-soc. I mean, would this
prevent conflicts when our branches are merged into linux-next, no
matter the order.

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html