Messages in this thread | | | Date | Mon, 13 Dec 2010 19:08:11 +0200 | From | Avi Kivity <> | Subject | Re: [PATCH] [104/223] KVM: Write protect memory after slot swap |
| |
On 12/13/2010 06:56 PM, Paul Gortmaker wrote: > On Mon, Dec 13, 2010 at 4:16 AM, Avi Kivity<avi@redhat.com> wrote: > > On 12/13/2010 11:12 AM, Andi Kleen wrote: > >> > >> > - Greg rejects kvm patches (but not virtio etc) pointing submitters > >> > to the kvm maintainers > >> > - The kvm maintainers collect stable kvm patches and autotest them > >> > >> As I understand this patch came in this way for .36 > >> (I took it from .36-stable) > > > > The patch was autotested for .36-stable, it wasn't autotested for > > .35-stable. It will very likely work (this isn't code that changes a lot), > > but still. > > > >> > - They then submit the patches to stable@ > >> > >> Do you want to do the autotest explicitely for .35 too and no automatic > >> backports and do the same procedure as for newer kernels? > >> > >> I can do that, but you would need to do it for a long time. > > > > Yes. In fact it gets more important as time goes by, since as time goes by > > patches are more likely to cause regressions due to changes in the code > > base. > > My workflow is largely the same as Andi's -- in that I'm using patches that > have already been nominated for other stable releases and putting them > on the 34-lt (longterm) as appropriate. Are you interested in also doing the > same thing for 34-lt (i.e. you generating a 34 specific, pre-tested patchset > instead of me doing the backports from other stable trees?)
Wait, there's a 34-lt too?
I'd like to have all stable kvms pass some minimum acceptance test, but that's quiet a lot of trees to maintain. Why do we have to have both 34-lt and 35-lt?
-- error compiling committee.c: too many arguments to function
| |