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 >