On 17/03/2016 14:44, Stefan Hajnoczi wrote: > > 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.
Great, let's try it then. For this series (well, for v2 of this series) only patches 1-4 would be considered infrastructure. They were sent before soft freeze, would they be acceptable for 2.6? In general I would send "safe" patches as [PATCH mm/nn] and everything else as [PATCH multiqueue mm/nn] or similar, but in either case I'd be seeking formal maintainer review as soon as I send them. Paolo
