On 7/22/26 13:09, Marc-André Lureau wrote:
On Wed, Jul 22, 2026 at 2:01 PM Philippe Mathieu-Daudé
<[email protected]> wrote:
On 22/7/26 11:38, Michael Tokarev wrote:
...
It would be nice if changes which should be picked up,
had Cc: qemu-stable@ in the first place, to avoid this
extra round-trip. I'm trying to keep it as simple as
possible, only asking to reply if I should not pick it
up, but it is more work for everyone still.
Indeed this patch should had a 'Cc: qemu-stable@' tag.
It could. That said, properly testing fixes on older releases takes
additional time and effort, and I prefer not to add Cc: qemu-stable@
unless I've verified the fix against those versions myself. I
appreciate you taking care of the stable evaluation, but I prefer to
keep my focus on master. Imho, we should not rush backports before
they have received a little bit more testing, it could introduce
regressions - the opposite of what I'd expect from -stable...
I understand your concerns well (hopefully anyway). However, I don't
really expect you to test things on older branches or to change your
focus, - it's not about that at all.
It is about just *marking* things which you, as the author of changes,
*think* might be good to fix/have in stable branches, so it gets some
attention later.
We can arrange "delayed stable queue" of sorts, we can wait for the
changes to prove themselves in the master branch, we can even try
to test the suggested changes in the stable branches - sometimes I
can do that too. But without having such attention in the first
place, none of this can happen, ever.
Right now I have to ask for every change which looks like a candidate,
whenever it is a candidate or not. This makes more work for you too,
by reading my emails and by cursing me making so much noise :)
Besides, with stable releases being not every second day but with some
delay, most stuff in there do have some minimal testing in the master
branch first, at the very least. It is just before the stable series
freeze things might look as rushing for stable. Also, a few years of
the stable series done this way already, kind of proves we're doing a
good job here. There was one regression in migration code which was
a tricky case by its own (it was broken either way), and one or two
more regressions fixed by a quick follow-up update, and that's all.
With so many changes in there, I think it's a rather good result.
Yes there's always risk to introduce a regression. Not doing any
fixing, on the other hand, ensures we stay with our bugs forever -
that would be the most stable stability :)
So, to make it explicit: I'm not asking your for more work -
especially not the extra testing of the changes in stable branches.
I only want to reduce your own work by not requiring to read my
questions when I feel something is a good candidate. Tagging the
change as "for-stable" does not mean it must be applied, it is
more about marking it as a to-do item, or some sort - for you
or for someone else. Just not to lose it.
Thanks,
/mjt
