Re: stable releases

[Michael Roth]

On Mon, Mar 06, 2023 at 09:57:58AM +0100, Thomas Huth wrote:
> On 05/03/2023 11.27, Michael Tokarev wrote:
> > Hi!
> > 
> > For a few qemu major releases already, we did not have any stable minor
> > releases.
> > I'd love to change that, in order to consolidate efforts and to make better
> > software in the end.  But I need some (hopefully minor) help here.
> > 
> > I collected changes from qemu/master which apparently should go to -stable.
> > Published at git://isrv.corpit.ru/qemu.git , branch stable-7.2-staging
> > (probably should publish it on github or gitlab).
> > This contains stuff which I use on Debian in qemu package, which is based
> > on 7.2 version now.  The last 18 patches are not in Debian package yet,
> > going to push it today or tomorrow.
> > 
> > If nothing, this can be used as a base for actual 7.2.1 stable release,
> > maybe with more changes added (or some changes removed).
> > 
> > The help which I need is to be able to run some wider testing. Debian is
> > a relatively good testbed, and it is used by qemu already in terms of
> > bullseye-backports to run other tests, so it should be good, but I'd
> > love to have wider coverage still. Maybe some CI stuff which qemu has
> > for master, if not only just before actual release.

Hi Michael,

Thank you for offering to help with the stable releases. I think it
would be in great hands and am happy to help in any way with getting
things going there.

I totally agree on Thomas' suggestions for next steps, and tried to
list out whatever else came to mind regarding stable releases in
general (sorry if things get a bit rambly).

> 
> I'd suggest to get a gitlab.com account, and fork the qemu repository there.
> Then you can run the CI on your own by pushing your patch to your forked
> repository.
> 
> You can also get some test additional coverage by running the avocado tests
> with "make check-avocado" ... but beware that this downloads quite some
> hundreds of MBs from the internet. And some tests are known to fail, so it's
> maybe best to run them on the plain 7.2.0 tag first to see what works for
> you and what does not work properly.

As far as testing, I think some other good tests/areas to consider eventually
adding would be:

  - qemu-iotests
  - VFIO/PCI passthrough tests of some sort if possible
  - live migration tests (especially things like 7.2.1 <-> 7.2.0
    migration compatibility to allow for rolling out/back live upgrades and
    things of that sort)
  - Windows guests

> 
> > And as usual, this needs help in picking up changes which should go to
> > stable. But this is something which is always needed anyway.
> > 
> > Let's resurrect qemu-stable :)

The "current" stable process is documented at docs/devel/stable-process.rst
As written, 7.2 support would end when 7.3/8.0 is released, and then
8.0.1 would be the next stable release afterward, but maybe there are more
optimal ways to integrate/schedule things in your case so don't feel
tied this approach.

As far as this release goes I'd recommend going ahead and getting your
stable-7.2-staging tree rebased on 7.2.0, along with whatever other patches
you think should definitely be included. For me this would include all CVE
fixes that went in after 7.2.0, and any patches tagged Cc:qemu-stable or
forwarded to qemu-stable mailing list. But that's another area to decide on
how you want to handle things. Maybe in some cases some important fixes
are better to get out sooner rather than trying to make every release
"complete".

I'd usually then post the staging tree to the mailing list to see if
there were any more candidates, which I think has pretty much always
identified more commits to pull in and proven worthwhile; but probably
depends on how frequently you cut releases. Maybe it makes sense to not
even do tagged releases, and just have a rolling stable tree? Things to
consider.

Ideally you'd be able to eventually push trees to the official QEMU repo
like I've done in the past. You'll need to work with the gitlab project
maintainers on that. But if you need to host/tag them in your own repo
until then that would probably be fine. Will want some way to
communicate this to QEMU community though, and official git repo is
probably the best way. I can also push your tree/tags as interim solution.

Will also need to figure out how to handle uploading tarballs (assuming
you still intend on distributing release tarballs). I can upload them
in the meantime, but we will probably want to work with Paolo getting
you access.

If there's anything else I can help with please let me know.

Thanks,

Mike

> 
> Please make sure to CC: qemu-stable and Michael Roth - I hope he can give
> some directions for this effort.
> 
>  Thomas
>