On 04/16/2012 03:47 PM, Alexander Graf wrote: > On 02.04.2012, at 11:46, Benjamin Herrenschmidt wrote: > > > On Mon, 2012-04-02 at 12:06 +0300, Avi Kivity wrote: > >>> The current process is such that it takes absolutely forever for our > >>> patches to get in, which is a major PITA for something in such state of > >>> active development. > >> > >> If the patches were posted two weeks earlier, they would have gone in. > > > > I believe on our side they were, but Alex took a while to make up his > > tree ... oh well.. > > Yes, because to me the kvm-ppc-next tree basically is the same semantically > as -next for Avi. It's where patches cook a while to make sure they actually > work. Nobody tests KVM PPC patches against kvm's master tree. All testing > (compile and execution) happens against kvm-ppc-next. > > That's why I don't see the point in having it cook again in Avi's tree. At > the end of the day the patches will surely become way too chewy ;).
kvm.git next is exposed to linux-next, where they get tested quite a lot. Granted it's mostly build testing, and people are unlikely to test kvm there, but they will test the non-kvm bits that creep in there. > The alternative would be that I don't have a -next tree, just collect patches > and immediately send them to Avi. That way the main kvm tree would be broken > more often, but at least we don't get these horrible synchronization > latencies. That works too. Don't post immediately; 2-3 week batches would reduce noise. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
