Re: [PULL 00/10] ppc queue

[Michael Tokarev]

29.05.2023 09:30, Nicholas Piggin wrote:
> On Mon May 29, 2023 at 4:01 PM AEST, Michael Tokarev wrote:
..
> > > They certainly fix some parts of target emulation, but what is the
> > > guidance for backporting those type of fixes? Most of the patches I sent
> > > including 2,3 were just found from inspection or new test code and not
> > > real software failing.
> > >
> > > Should just simple ones go in? 32-bit SPRs do not fix entirely the
> > > behaviour of all SPRs, just one aspect. In another fix I had (that
> > > didn't make it in this merge), was a bit more complicated and the
> > > first iteration caused a deadlock that didn't show up in basic test
> > > like booting Linux.
> > >
> > > My guess is that fixes that correct an issue with real software running
> > > on the target should be ported to stable. Perhaps "obviously correct"
> > > small fixes as well. But not sure about larger changes.
> >
> > This is exactly why I asked, - because I don't clearly understand how
> > important these to have in -stable. And also to remind that -stable
> > exist, just in case.. ;)
>
> Ah okay, makes sense. I was just clarifying myself since I wasn't
> too sure.

We do not have strict rules for stuff which should go to -stable.
In the wiki - https://www.qemu.org/docs/master/devel/stable-process.html -
it is stated as vague as

  If you think the patch would be important for users of the current release
  (or for a distribution picking fixes), it is usually a good candidate for 
stable.

so things are decided on a case-by-case basis.  Sometimes even spelling
fixes gets picked up, sometimes much larger and invasive changes has to
be picked to fix a real bug.  Once again, there's no strict rules.

Myself, I haven't been in this process before, but I see it from a
downstream PoV, as I maintain qemu in debian for quite some years.

A bug might not be reported by actual users, but if it has good potential
for breaking something, - *maybe* like in this case when qemu behaves
differently than an actual HW (once again, I don't know what the impact
of *these* fixes, or lack thereof, are), - and at the same time the
fix is small, self-contained and "obviously correct" (in other words,
has low potential of breaking something else), - I tend to pick it up,
to bring behavior to match the specs like in this case.

We had this numerous times: something is broken, but apparently no one
uses that. And out of the sudden people start hitting it in real life,
like even qemu itself which uses debian-provided packages in its own CI.
Just to discover this bug is known for a long time and is fixed in master
long ago too.

Sure thing there might be changes which fix more serious issues, but which
are based on some subsystem rewrite, - with these, it's more difficult to
decide what to do - to keep bug or to risk breaking other stuff.  I omitted
a few fixes for 7.2 due to this very situation: when the infrastructure
used in new code did not exist in 7.2 and quite a lot of other changes
needs to be back-ported.

There's always a tradeoff: the "importance" of the bug and the amount of
stuff it requires to back-port. Unimportant fixes (eg, a missing free()
in error path in init function) which require other code changes are
obviously not for -stable.  On the other end, small but important changes
(eg a fix for a crash/deadlock which many users are hitting) is obviously
a good fit for -stable.  And anything in-between is, sure thing, grey,
with all its shades.

This is why we're more dependent on the subsystem maintainers or authors
of the particular changes, - since they know much better when any given
fix is important or not, know much better about possible impact and so on.
Maybe it's just cosmetics which can safely be ignored, or maybe it's a
big thing which is worth to backport other stuff for it to work.
It is also much easier to think about this when you have the context
which you just fixed, still in your mind.

And this is why I'm asking.

Thank you!

/mjt