On Wed, Mar 16, 2016 at 11:29:02PM +0100, Paolo Bonzini wrote: > On 16/03/2016 19:18, Stefan Hajnoczi wrote: > > Looks good overall. I'm a little nervous about merging it for QEMU 2.6 > > but the block job, NBD, and data plane tests should give it a good > > workout. > > Apart from QEMU nearing hard freeze, I totally understand not wanting to > commit to merging part 1 of n where n will probably be a dozen or so. > I'm open to experimenting with different models for handling long-term > contributions. > > For example, each part will probably have an uncontroversial and > generally useful prefix---for example patches 1-4 in this case, or the > change to a single linux-aio context per iothread. You could merge > those only, and for the rest, I will maintain myself a branch with R-b > from maintainers. Master will be periodically merged into it, but not > too frequently---it could be only after each part is accepted, or when > there is some important bugfix to catch. Once the whole multiqueue > thing gets somewhere I would send you a pull request with the entire > feature, which would consist of say 200 patches all with a Reviewed-by > already. > > This is just a possibility; if you have any other idea, I'd be happy to > follow it.
That sounds reasonable. I guess you are sending a) infrastructure and safe changes alongside b) longer-term work. If you indicate which patches are a) then that makes it easier to merge parts into qemu.git before all the long-term work is complete. Stefan
signature.asc
Description: PGP signature
