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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
