mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@de.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>, torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, rkrcmar@redhat.com,
	kvm@vger.kernel.org,
	Christoffer Dall <christoffer.dall@linaro.org>,
	Dan Williams <dan.j.williams@intel.com>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Paul Mackerras <paulus@ozlabs.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>
Subject: Re: [GIT PULL] KVM changes for 4.8 merge window
Date: Tue, 2 Aug 2016 20:02:53 +0200	[thread overview]
Message-ID: <e9b5bf31-5d68-1eb6-3706-2965bfd98c8c@de.ibm.com> (raw)
In-Reply-To: <1470141468-120437-1-git-send-email-pbonzini@redhat.com>

On 08/02/2016 02:37 PM, Paolo Bonzini wrote:
[snip]
lots of conflicts all over the place
[snip]

looks like all architectures collected their merge conflicts for a year 
in one release...
 
> - 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 
1. to route everything that conflicts via Martins s390 (thus bypassing the 
kvm tree) - which then means to route everything in arch/s390/kvm/
via Martin as I would conflict with myself otherwise. Of course cross-architecture
changes in arch/*/kvm could then cause other conflicts.
2. do non-kvm via arch tree and wait for a full merge window to add the 
dependencies. Of course this might not work as things are moving and will slow
down things a lot

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 the end a merge conflict might be just the right thing over rebases - this time it
was just a lot.

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. You would have to rebase the kvm/next tree to avoid the conflict
with the 2nd one - which is a bad idea for a tree that has downstream users.

We might want to have a better way of just getting the fixes from next.
All s390 fixups in next have been there since end of June. So over a month
of test coverage.

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


> 
> 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/

Christian

  reply	other threads:[~2016-08-02 21:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-02 12:37 Paolo Bonzini
2016-08-02 18:02 ` Christian Borntraeger [this message]
2016-08-02 18:42   ` Linus Torvalds
2016-08-02 20:17     ` Linus Torvalds
2016-08-02 20:49       ` Christian Borntraeger
2016-08-02 21:36       ` Martin Schwidefsky
2016-08-02 21:46         ` Linus Torvalds
2016-08-02 18:55   ` Paolo Bonzini
2016-08-03  3:21 ` Michael Ellerman
2016-08-03  6:26   ` Paolo Bonzini
2016-08-03  6:46     ` Michael Ellerman
2016-08-03 11:00       ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e9b5bf31-5d68-1eb6-3706-2965bfd98c8c@de.ibm.com \
    --to=borntraeger@de.ibm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=dan.j.williams@intel.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@ozlabs.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=schwidefsky@de.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®