On Thu, Mar 7, 2013 at 11:09 AM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > On Thu, Mar 07, 2013 at 07:57:23AM +0100, Marc Zyngier wrote: >> On Wed, 6 Mar 2013 20:40:00 -0800, Christoffer Dall >> <cdall@xxxxxxxxxxxxxxx> >> wrote: >> > On Wed, Mar 6, 2013 at 7:54 PM, Marc Zyngier <marc.zyngier@xxxxxxx> >> wrote: >> >> On Wed, 6 Mar 2013 16:31:48 -0800, Christoffer Dall >> >> <cdall@xxxxxxxxxxxxxxx> >> >> wrote: >> >> >> >> Hi Christoffer, >> >> >> >>> >> >>> Please pull these KVM/ARM fixes mostly centered around preparation for >> >>> Marc's ARMv8 KVM work. >> >> >> >> Can we please hold on that for a while? asm-offset.c is usually a >> >> candidate for merge conflicts as people start pushing patches post >> merge >> >> window, and it would make sense to see what is happening in that space. >> >> >> > Sure, when would you see this happen exactly? >> >> Usually, by -rc5 we have a pretty good idea of what is going in. Also, >> putting things into -next is a good way to detect potential problems. >> >> Oh, and keeping linux-arm-kernel into the loop. Most ARM developers don't >> follow the KVM lists. >> >> M. > > Mark, can you please be more verbose on the reason for this request? > > Christoffer, patches which are not causing merge conflicts can be > integrated (note that the merge window exists so that development code > can sit on a development branch and be tested before integration). > > After the merge window has closed, patches whose purpose is to stabilize > the code base are supposed to be integrated, and development code queued > for the next merge window. > Understood and agreed. Since the patches I sent a pull request for fixes code (although not bugs) and are trivial and would not cause breakage, I think they should be merged into kvm/master. This is anyhow going to be a judgement call in the future, and I can certainly adjust my evaluations as we go along in the future, but I don't see the harm in honoring this pull request. -Christoffer -- 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