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