Re: Preparing kvm/next for first pull request of 3.15 merge window

[Paolo Bonzini <pbonzini@redhat.com>]

Il 25/03/2014 21:35, Christian Borntraeger ha scritto:
> On 25/03/14 18:29, Paolo Bonzini wrote:
>> Also, the pull requests I got in the last couple of months were a bit
>> messy, and I'm already fearing that Linus notices. In the future, I'll
>> tag kvm-3.x-base (e.g. kvm-3.16-base) when I open kvm/next, and I will
>> *reject* pull requests from submaintainers that include extra non-KVM
>> commits without a very good reason.
>
> can you clarify this statement? What are the dont do things: (I already checked one obvious answer)
>
> [ ] I include non-kvm s390 patches (with a Maintainer ack from Martin
> or Heiko) which are required for other patches. These patches might
> even go via the s390 tree as well

This is okay.  The patches will stand out in the diffstat and I'll check 
that they have Acked-bys before pulling.  Bonus for using signed tags 
and mentioning it in the tag message. :)

> [ ] My pull request is based on current kvm/next instead of kvm/next
> that was branched away after rc1

This is not only okay, it's almost always desirable.  It's also okay to 
base your pull request on your last pull request.  Any commit between 
kvm-3.x-base and kvm/next will do.

Exception: if there is a particularly important bugfix that you want in 
both -rc and kvm/next, make the pull request based on kvm-3.x-base. 
After pulling it in kvm/next, I'll "forward" the pull request 
immediately to Linus.  But it should happen very rarely, and only for 
very bad bugs introduced during the last merge window.

For an example, see https://lkml.org/lkml/2014/3/18/112.

> [X] My pull request is based on 3.x-rcy instead of kvm/next

Indeed this is bad and it is my main complaint.  As mentioned above, 
pull requests should be based on a commit between kvm-3.x-base and kvm/next.

> [ ] My pull request is based on kvm/queue instead of kvm/next

This is not bad per se, but kvm/queue can be rebased: if down the line I 
have problems with kvm/queue, you'll have to resend the pull request.

In fact, there should be no need to base pull requests on kvm/queue. 
Even if your arch-specific patches touch virt/kvm/ or have prerequisites 
in virt/kvm/, it is better to harass me until I test kvm/queue and merge 
it back into kvm/next. :)

Paolo