On Thu, Mar 17, 2016 at 02:48:00PM +0100, Paolo Bonzini wrote: > > > 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.
Okay. I'll hope over to the v2 series to take a look. Stefan
signature.asc
Description: PGP signature
