Date:	Tue, 2 Aug 2016 14:55:29 -0400 (EDT)
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Christian Borntraeger <borntraeger@...ibm.com>
Cc:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	rkrcmar@...hat.com, kvm@...r.kernel.org,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Dan Williams <dan.j.williams@...el.com>,
	Marc Zyngier <marc.zyngier@....com>,
	Paul Mackerras <paulus@...abs.org>,
	Michael Ellerman <mpe@...erman.id.au>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Heiko Carstens <heiko.carstens@...ibm.com>
Subject: Re: [GIT PULL] KVM changes for 4.8 merge window


> looks like all architectures collected their merge conflicts for a year
> in one release...

Yes, pretty much.  MIPS had conflicts too; however I applied their patches
instead of going through a pull request, so I did the topic branch dance
myself. :)

> > - arch/s390: also messy.  First is hypfs_diag.c where the KVM tree
> > moved some code and the s390 tree patched it.  You have to reapply the
> > relevant part of commits 6c22c9863760, plus all of e030c1125eab, to
> > arch/s390/kernel/diag.c.  Or pick the linux-next conflict
> > resolution from http://marc.info/?l=kvm&m=146717549531603&w=2.
> > Second, there is a conflict in gmap.c between a stable fix and 4.8.
> > The KVM version here is the correct one.
> 
> Adding Heiko and Martin,
> 
> I think this time it was really tricky, but I cannot see a way to avoid these
> 2 conflicts other than

For the diag conflict, the right thing to do would have been the following:

1) Janosch sends the patch to Martin

2) Martin prepares a topic branch with Janosch's patch only

3) Both Martin and you pull the topic branch

4) you send the pull request normally to me.

> The topic branch variant of x86 only works because Ingos tip request are
> always pulled before kvm it seems. There is no guaranteed order if s390 or
> kvm comes first, though - so If I rebase at rc7 on a topic branch from Martin,
> then Linus might pull s390 changes via Paolo - I do not think this is ok.

In general architectures come first.  I rarely send pull requests before
the first Thursday of the merge window because KVM comes after architecture
trees in linux-next.  This lets me double check my own conflict resolution
against Stephen's one from the linux-next emails.

> Lets have a look at the s390 diag move: Actually the kvm patch has the oldest
> commit date, but the other two patches are real bugfixes that came after
> that.

That's fine.  That means the conflicts would have come nevertheless to Linus,
but that would have happened through Martin's tree rather than mine.

Note that there's a way to avoid this kind of conflicts too.  Base
the stable fixes topic branch on `git merge-base kvm/master kvm/next`,
and ask me to pull into both kvm/master and kvm/next.  It's not always
necessary, but it's good to know it and it pushes the conflict away
from Linus (which AFAIK wants to see conflicts between subsystems but
is not necessary interested in conflicts between -rc and merge window
material).  I did this for MIPS for example.

> Linus, do you use next as a tie-breaker for merge resolutions or is there
> a natural way of getting the fixups from Stephen?

AFAIK it's a mixture between looking at histories himself and relying on
explanations from submaintainers (which in turn may refer to linux-next).

> > I have pushed my resolution at refs/heads/merge-20160802 (commit
> > 3d1f53419842) at git://git.kernel.org/pub/scm/virt/kvm/kvm.git.
> 
> I checked this resolution. To make things complete
> There is another fixup necessary for s390, see
> 
> https://patchwork.kernel.org/patch/9162647/

Great, thanks.  I must admit I forgot about this one (I confused it
with the commit that introduced nopr in __diag204).

Paolo

Powered by blists - more mailing lists