* [PULL][v2] Memory API fix
@ 2011-08-22 16:54 ` Avi Kivity
0 siblings, 0 replies; 5+ messages in thread
From: Avi Kivity @ 2011-08-22 16:54 UTC (permalink / raw)
To: Anthony Liguori, qemu-devel; +Cc: KVM list
[v2: fix git url...]
Anthony, please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core
to receive a memory API fix. The fix is not required for any of the
already merged patches, but is needed by other patches in my queue.
I am sending core patches separately than the conversions to increase
their visibility.
(and I'll take this opportunity to announce a new layout for the branch:
- memory/core - core fixes, usually not rebased
- memory/batch - pending batch
- memory/queue - the rest of the patches in my queue
- memory/master - a merge of the first three; please post patches
based on this branch
this will allow me to fast-path core fixes without rebasing
memory/batch, except when a dependency is involved.)
Richard Henderson (1):
memory: Fix old_portio vs non-zero offset
memory.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Qemu-devel] [PULL][v2] Memory API fix
@ 2011-08-22 16:54 ` Avi Kivity
0 siblings, 0 replies; 5+ messages in thread
From: Avi Kivity @ 2011-08-22 16:54 UTC (permalink / raw)
To: Anthony Liguori, qemu-devel; +Cc: KVM list
[v2: fix git url...]
Anthony, please pull from:
git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core
to receive a memory API fix. The fix is not required for any of the
already merged patches, but is needed by other patches in my queue.
I am sending core patches separately than the conversions to increase
their visibility.
(and I'll take this opportunity to announce a new layout for the branch:
- memory/core - core fixes, usually not rebased
- memory/batch - pending batch
- memory/queue - the rest of the patches in my queue
- memory/master - a merge of the first three; please post patches
based on this branch
this will allow me to fast-path core fixes without rebasing
memory/batch, except when a dependency is involved.)
Richard Henderson (1):
memory: Fix old_portio vs non-zero offset
memory.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 5+ messages in thread
* Merging invasive changes (Was Re: [Qemu-devel] [PULL][v2] Memory API fix)
2011-08-22 16:54 ` [Qemu-devel] " Avi Kivity
@ 2011-08-22 17:16 ` Anthony Liguori
-1 siblings, 0 replies; 5+ messages in thread
From: Anthony Liguori @ 2011-08-22 17:16 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, KVM list
Hi,
This is a summary from a discussion Avi and I had earlier about merging
invasive changes (like the memory API) into the tree in a more fluid
fashion. Here's my suggestions:
- Invasive changes over a long period of time (multi batches) should be
done via git pull. patch (and therefore git-am) sucks at resolving
conflicts which are a given for these types of changes. git-merge is
much better at this.
- Pull requests should be prefixed with '[PULL]'.
- Patches should go to the ML as often as they are created. Small sets
of patches can depend on each other. Don't dump 40 patches and then
submit a pull request the next day.
- Pull requests should be batched in a 1-2 week period after having
received reviews or sufficient time to be reviewed. If it's something
that really needs review, make sure it gets review before doing the pull
request. Good judgement is required here. Batching is important to
avoid breaking the tree daily. Exceptions will happen and that's okay,
but they should be exceptions.
- Patches destined for a subsystem should be prefixed with a subsystem
marker. For instance, '[PATCH] block: fix QED blah blah'. If I see the
prefix for a known maintained subsystem, I will delete the patch from my
own queue.
- Subsystems are 'known maintained' by having an entry in MAINTAINERS
and by having a responsive maintainer.
- Invasive, but mechanical changes shouldn't be overly split. 60 four
line patches that makes the same pattern of change are harder to review
than 6 forty line patches that apply the same pattern repeatedly.
- Non-mechanical changes should be split of course based on logical
functional areas.
Regards,
Anthony Liguori
On 08/22/2011 11:54 AM, Avi Kivity wrote:
> [v2: fix git url...]
>
> Anthony, please pull from:
>
> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core
>
> to receive a memory API fix. The fix is not required for any of the
> already merged patches, but is needed by other patches in my queue.
>
> I am sending core patches separately than the conversions to increase
> their visibility.
>
>
> (and I'll take this opportunity to announce a new layout for the branch:
>
> - memory/core - core fixes, usually not rebased
> - memory/batch - pending batch
> - memory/queue - the rest of the patches in my queue
> - memory/master - a merge of the first three; please post patches based
> on this branch
>
> this will allow me to fast-path core fixes without rebasing
> memory/batch, except when a dependency is involved.)
>
> Richard Henderson (1):
> memory: Fix old_portio vs non-zero offset
>
> memory.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Qemu-devel] Merging invasive changes (Was Re: [PULL][v2] Memory API fix)
@ 2011-08-22 17:16 ` Anthony Liguori
0 siblings, 0 replies; 5+ messages in thread
From: Anthony Liguori @ 2011-08-22 17:16 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, KVM list
Hi,
This is a summary from a discussion Avi and I had earlier about merging
invasive changes (like the memory API) into the tree in a more fluid
fashion. Here's my suggestions:
- Invasive changes over a long period of time (multi batches) should be
done via git pull. patch (and therefore git-am) sucks at resolving
conflicts which are a given for these types of changes. git-merge is
much better at this.
- Pull requests should be prefixed with '[PULL]'.
- Patches should go to the ML as often as they are created. Small sets
of patches can depend on each other. Don't dump 40 patches and then
submit a pull request the next day.
- Pull requests should be batched in a 1-2 week period after having
received reviews or sufficient time to be reviewed. If it's something
that really needs review, make sure it gets review before doing the pull
request. Good judgement is required here. Batching is important to
avoid breaking the tree daily. Exceptions will happen and that's okay,
but they should be exceptions.
- Patches destined for a subsystem should be prefixed with a subsystem
marker. For instance, '[PATCH] block: fix QED blah blah'. If I see the
prefix for a known maintained subsystem, I will delete the patch from my
own queue.
- Subsystems are 'known maintained' by having an entry in MAINTAINERS
and by having a responsive maintainer.
- Invasive, but mechanical changes shouldn't be overly split. 60 four
line patches that makes the same pattern of change are harder to review
than 6 forty line patches that apply the same pattern repeatedly.
- Non-mechanical changes should be split of course based on logical
functional areas.
Regards,
Anthony Liguori
On 08/22/2011 11:54 AM, Avi Kivity wrote:
> [v2: fix git url...]
>
> Anthony, please pull from:
>
> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core
>
> to receive a memory API fix. The fix is not required for any of the
> already merged patches, but is needed by other patches in my queue.
>
> I am sending core patches separately than the conversions to increase
> their visibility.
>
>
> (and I'll take this opportunity to announce a new layout for the branch:
>
> - memory/core - core fixes, usually not rebased
> - memory/batch - pending batch
> - memory/queue - the rest of the patches in my queue
> - memory/master - a merge of the first three; please post patches based
> on this branch
>
> this will allow me to fast-path core fixes without rebasing
> memory/batch, except when a dependency is involved.)
>
> Richard Henderson (1):
> memory: Fix old_portio vs non-zero offset
>
> memory.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Qemu-devel] [PULL][v2] Memory API fix
2011-08-22 16:54 ` [Qemu-devel] " Avi Kivity
(?)
(?)
@ 2011-08-22 17:29 ` Anthony Liguori
-1 siblings, 0 replies; 5+ messages in thread
From: Anthony Liguori @ 2011-08-22 17:29 UTC (permalink / raw)
To: Avi Kivity; +Cc: qemu-devel, KVM list
On 08/22/2011 11:54 AM, Avi Kivity wrote:
> [v2: fix git url...]
>
> Anthony, please pull from:
>
> git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git memory/core
Pulled. Thanks.
Regards,
Anthony Liguori
>
> to receive a memory API fix. The fix is not required for any of the
> already merged patches, but is needed by other patches in my queue.
>
> I am sending core patches separately than the conversions to increase
> their visibility.
>
>
> (and I'll take this opportunity to announce a new layout for the branch:
>
> - memory/core - core fixes, usually not rebased
> - memory/batch - pending batch
> - memory/queue - the rest of the patches in my queue
> - memory/master - a merge of the first three; please post patches based
> on this branch
>
> this will allow me to fast-path core fixes without rebasing
> memory/batch, except when a dependency is involved.)
>
> Richard Henderson (1):
> memory: Fix old_portio vs non-zero offset
>
> memory.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-08-22 17:29 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-22 16:54 [PULL][v2] Memory API fix Avi Kivity
2011-08-22 16:54 ` [Qemu-devel] " Avi Kivity
2011-08-22 17:16 ` Merging invasive changes (Was Re: [Qemu-devel] [PULL][v2] Memory API fix) Anthony Liguori
2011-08-22 17:16 ` [Qemu-devel] Merging invasive changes (Was " Anthony Liguori
2011-08-22 17:29 ` [Qemu-devel] [PULL][v2] Memory API fix Anthony Liguori
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.