On Wed, 2026-07-15 at 15:30 +0300, Michael Tokarev wrote: > On 7/14/26 07:19, Alistair Francis wrote: > [..] > > Assuming that we don't backport plugin fixes then nothing in this > > PR > > should be backported to stable. > > I was afraid you might feel uncomfortable, after recent my emails > about qemu-stable in context of riscv. But everything I'm trying > to do are attempts to make things easier, not more complicated :)
Not at all! I just feel guilty that you are picking up the slack and trying to make things easier/clearer > Maybe I wanted too much, asking if there's something for stable > in every riscv pullreq in the past :) I felt that was just because I was doing a bad job of indicating what should be backproted. > > I learned about the riscv pull requests - everything with Fixes and > Resolves should be picked up. That's okay with me. I think I'll That seems like a good starting place. I can CC qemu-stable on anything else that stands out. Do others not do something similar? Fixes and Resolves seems like the perfect indicator for backporting. > take it easier - pick things up for the most recent stable series > (currently 11.0.x), and for older/LTS series, I'll take just what > can be easily applied - to avoid losing everyone's time and patience > in long discussions about what needs to be picked up and what should > not. As long as riscv don't have versioned machines in qemu, I > assume it is a fast-moving target, so older qemu is not very relevant > for it anymore (because besides fixes, older versions don't have many > required features too, developed later), and there's no need to spend > significant resources in that area. That all seems reasonable to me. It's tricky as it is moving fast and we have things like draft extensions, which makes more complex. Alistair > > Hopefully this roadmap will work :) > > Thanks, > > /mjt
