On 01/11/2012 11:48 PM, Alexander Graf wrote: > > > > Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet. We can't release any qemu that depends on something not upstream. > The question again is: When do we consider something upstream? This far from a qemu release, we can consider anything in in kvm.git master (or slightly trailing that, kvm.git linux-next) as upstream. It's very rare that an ABI gets pulled out of that and not merged, and if it is, we can pull out the qemu feature. An ABI can change, but that just means we need to echo the change in qemu. As qemu gets closer to release, we'll need to look at Linus' tree instead of kvm.git. > >> > >> right? And then after about 3 months we'll have the feature available ;). > > > > You can always just get Acked-by's from the appropriate maintainers. That's just as good as going through the tree. > > So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :) Of course I can complain about my patches later. Complained-about-by: Avi Kivity <avi@xxxxxxxxxx> But yes, if your change involves multiple subsystem, get it through the most affected subsystem and get acks from the rest. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
