From: Avi Kivity <avi@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: Re: New kvm-related qemu patch queue
Date: Sun, 10 Jan 2010 16:30:44 +0200 [thread overview]
Message-ID: <4B49E494.3030400@redhat.com> (raw)
In-Reply-To: <20100110142820.GN4905@redhat.com>
On 01/10/2010 04:28 PM, Gleb Natapov wrote:
> On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
>
>> In order to improve qemu.git kvm integration quality wrt
>> performance, features, and reliability Marcelo and I will begin to
>> maintain a patch queue based on qemu.git containing kvm-related
>> patches. We will review and apply patches to this queue, test them
>> using the same test suite that is used for qemu-kvm.git, and
>> regularly submit them for inclusion in qemu.git, mimicking the
>> relationship between kvm.git and Linus' linux-2.6.git.
>>
>> One of the problems of qemu.git kvm support is that it is a clean
>> reimplementation, and thus some of the nuances that were carefully
>> ironed out in qemu-kvm.git are lost. To that end, we would like to
>> change the process of adding features as follows:
>>
>> - first, the feature in qemu-kvm.git master is morphed to a form
>> suitable for merging into qemu.git
>> - when that has been accomplished, the feature is broken into
>> patches and merged into the patch queue
>>
>>
> If there is the same feature in qemu-kvm.git and qemu.git whom is morphed to
> whom and who is merged where? I am confused. We have much of duplicated
> code between qemu-kvm.git and qemu.git it is often almost, but not exactly the
> same. Is it really productive to set rules who should be morphed and how
> at this point?
>
If the feature is already in both, then morph qemu-kvm.git into what is
already in qemu.git. Hopefully anything missing in qemu.git will be
discovered while making the changes.
>> In order to get a kvm feature into qemu.git, please observe the
>> following process:
>>
>> - post a patch series against qemu-kvm.git/master that implements
>> the feature, or changes an existing feature to use qemu.git
>> infrastructure
>>
> It was other way around till last week. Why change?
>
There were a lot of regressions.
--
error compiling committee.c: too many arguments to function
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: [Qemu-devel] Re: New kvm-related qemu patch queue
Date: Sun, 10 Jan 2010 16:30:44 +0200 [thread overview]
Message-ID: <4B49E494.3030400@redhat.com> (raw)
In-Reply-To: <20100110142820.GN4905@redhat.com>
On 01/10/2010 04:28 PM, Gleb Natapov wrote:
> On Sun, Jan 10, 2010 at 02:02:27PM +0200, Avi Kivity wrote:
>
>> In order to improve qemu.git kvm integration quality wrt
>> performance, features, and reliability Marcelo and I will begin to
>> maintain a patch queue based on qemu.git containing kvm-related
>> patches. We will review and apply patches to this queue, test them
>> using the same test suite that is used for qemu-kvm.git, and
>> regularly submit them for inclusion in qemu.git, mimicking the
>> relationship between kvm.git and Linus' linux-2.6.git.
>>
>> One of the problems of qemu.git kvm support is that it is a clean
>> reimplementation, and thus some of the nuances that were carefully
>> ironed out in qemu-kvm.git are lost. To that end, we would like to
>> change the process of adding features as follows:
>>
>> - first, the feature in qemu-kvm.git master is morphed to a form
>> suitable for merging into qemu.git
>> - when that has been accomplished, the feature is broken into
>> patches and merged into the patch queue
>>
>>
> If there is the same feature in qemu-kvm.git and qemu.git whom is morphed to
> whom and who is merged where? I am confused. We have much of duplicated
> code between qemu-kvm.git and qemu.git it is often almost, but not exactly the
> same. Is it really productive to set rules who should be morphed and how
> at this point?
>
If the feature is already in both, then morph qemu-kvm.git into what is
already in qemu.git. Hopefully anything missing in qemu.git will be
discovered while making the changes.
>> In order to get a kvm feature into qemu.git, please observe the
>> following process:
>>
>> - post a patch series against qemu-kvm.git/master that implements
>> the feature, or changes an existing feature to use qemu.git
>> infrastructure
>>
> It was other way around till last week. Why change?
>
There were a lot of regressions.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-01-10 14:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-10 12:02 New kvm-related qemu patch queue Avi Kivity
2010-01-10 12:02 ` [Qemu-devel] " Avi Kivity
2010-01-10 14:28 ` Gleb Natapov
2010-01-10 14:28 ` [Qemu-devel] " Gleb Natapov
2010-01-10 14:30 ` Avi Kivity [this message]
2010-01-10 14:30 ` Avi Kivity
2010-01-10 14:49 ` Gleb Natapov
2010-01-10 14:49 ` [Qemu-devel] " Gleb Natapov
2010-01-10 14:52 ` Avi Kivity
2010-01-10 14:52 ` [Qemu-devel] " Avi Kivity
2010-01-11 7:51 ` Gleb Natapov
2010-01-11 7:51 ` [Qemu-devel] " Gleb Natapov
2010-01-11 15:30 ` Anthony Liguori
2010-01-11 15:30 ` [Qemu-devel] " Anthony Liguori
2010-01-17 12:51 ` Avi Kivity
2010-01-17 12:51 ` [Qemu-devel] " Avi Kivity
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=4B49E494.3030400@redhat.com \
--to=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=qemu-devel@nongnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.