Re: stable releases
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 >
Re: stable releases
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. 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. 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 :) Please make sure to CC: qemu-stable and Michael Roth - I hope he can give some directions for this effort. Thomas
stable releases
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. 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 :) Thanks, /mjt
Re: [Qemu-devel] Qemu stable releases
Am 09.12.2011 14:24, schrieb Anthony Liguori: > On 12/09/2011 06:55 AM, Andreas Färber wrote: >> Am 05.12.2011 21:08, schrieb Justin M. Forbes: >>> Typically I get a flurry of patches shortly after >>> a release (and they have already started for 1.0). I have tried to get >>> a .1 release out in a timely manner, and then it seems patches for >>> stable become few and far between. In the 0.14 and 0.15 series, not >>> even enough to warrant a .2 release. Perhaps this is due to lack fixed >>> issues, or lack of effort to submit to stable. >> >>> 3) Security fixes do not follow this schedule, and will trigger a stable >>> release as needed. >> >> I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu >> and qemu-kvm. I am surprised nothing has happened there yet... >> >> http://patchwork.ozlabs.org/patch/128064/ > > We don't have a clear EOL schedule for stable releases. Historically, > stable releases only lasted until the next release cycle so in by that > logic, 0.15 is EOL. Unfortunately qemu(-kvm) 1.0 came too late for SLES 11 SP2, so we're now forced to ship 0.15.1 plus a ton of hand-picked patches. Therefore I would appreciate finding some solution to keep 0.15 branch usable, whatever tarballs you release on qemu.org or declare EOL. Regards, Andreas > Obviously, part of creating a regular cadence for stable releases and > getting more people involved is to formalize this all quite a bit more. > > Regards, > > Anthony Liguori -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Qemu stable releases
On Fri, Dec 09, 2011 at 07:25:39AM -0600, Anthony Liguori wrote: > On 12/09/2011 06:01 AM, Richard W.M. Jones wrote: > >On Fri, Dec 09, 2011 at 10:39:37AM +, Richard W.M. Jones wrote: > >>FWIW in libguestfs we have such a policy. Every few weeks I evaluate > >>_all_ commits along the development branch and cherry pick those that > >>meet this policy back to the stable branch, followed by making a new > >>stable release. Here is the policy: > >> > >>http://libguestfs.org/guestfs.3.html#libguestfs_version_numbers > >> from "Our criteria for backporting changes are ..." > > Out of curiosity, what's the commit rate for libguestfs and what's > the release schedule? A lot less than qemu. I can't update my qemu.git at the moment but there are 810 commits in libguestfs since 2010-12-31, and maybe 50x as many in qemu over the same period. Release schedule is not fixed, but it seems to average to a new stable branch every 3-4 months. > I tried this years ago with QEMU and while it resulted in a very > active stable branch, it was a huge amount of work, particularly as > we got about half way through the next development cycle. I generally don't backport fixes if the cherry picking involves complicated changes, because that's against the policy that fixes in the stable branch need to be well-tested and uncontroversial. A massive cherry pick rewrite is by definition not a well-tested change. Splitting development commits helps: eg. if new features are split into non-functional code motion commits + new feature commits. We tend to backport code motion changes, which helps to make cherry picking bug fixes simpler because the code in both branches stays similar. Anyhow, there you go, it may not work for qemu. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
Re: [Qemu-devel] Qemu stable releases
On Fri, 2011-12-09 at 13:55 +0100, Andreas Färber wrote: > Am 05.12.2011 21:08, schrieb Justin M. Forbes: > > Typically I get a flurry of patches shortly after > > a release (and they have already started for 1.0). I have tried to get > > a .1 release out in a timely manner, and then it seems patches for > > stable become few and far between. In the 0.14 and 0.15 series, not > > even enough to warrant a .2 release. Perhaps this is due to lack fixed > > issues, or lack of effort to submit to stable. > > > 3) Security fixes do not follow this schedule, and will trigger a stable > > release as needed. > > I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu > and qemu-kvm. I am surprised nothing has happened there yet... > > http://patchwork.ozlabs.org/patch/128064/ > I suppose that also brings up the question of how long a stable branch should be supported? Perhaps we should do stable through 2 release cycles, so that 0.15 stable would stop when 1.1 is released? Justin
Re: [Qemu-devel] Qemu stable releases
On 12/09/2011 06:01 AM, Richard W.M. Jones wrote: On Fri, Dec 09, 2011 at 10:39:37AM +, Richard W.M. Jones wrote: FWIW in libguestfs we have such a policy. Every few weeks I evaluate _all_ commits along the development branch and cherry pick those that meet this policy back to the stable branch, followed by making a new stable release. Here is the policy: http://libguestfs.org/guestfs.3.html#libguestfs_version_numbers from "Our criteria for backporting changes are ..." Out of curiosity, what's the commit rate for libguestfs and what's the release schedule? I tried this years ago with QEMU and while it resulted in a very active stable branch, it was a huge amount of work, particularly as we got about half way through the next development cycle. Regards, Anthony Liguori For completeness, here is an example stable branch containing cherry-picked commits: http://fedorapeople.org/git/?p=rjones/public_git/libguestfs.git;a=log;h=refs/remotes/origin/stable-1.14 Compare to the master branch to see which commits did and didn't make it in. Rich.
Re: [Qemu-devel] Qemu stable releases
On 12/09/2011 06:55 AM, Andreas Färber wrote: Am 05.12.2011 21:08, schrieb Justin M. Forbes: Typically I get a flurry of patches shortly after a release (and they have already started for 1.0). I have tried to get a .1 release out in a timely manner, and then it seems patches for stable become few and far between. In the 0.14 and 0.15 series, not even enough to warrant a .2 release. Perhaps this is due to lack fixed issues, or lack of effort to submit to stable. 3) Security fixes do not follow this schedule, and will trigger a stable release as needed. I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu and qemu-kvm. I am surprised nothing has happened there yet... http://patchwork.ozlabs.org/patch/128064/ We don't have a clear EOL schedule for stable releases. Historically, stable releases only lasted until the next release cycle so in by that logic, 0.15 is EOL. Obviously, part of creating a regular cadence for stable releases and getting more people involved is to formalize this all quite a bit more. Regards, Anthony Liguori Andreas
Re: [Qemu-devel] Qemu stable releases
Am 05.12.2011 21:08, schrieb Justin M. Forbes: > Typically I get a flurry of patches shortly after > a release (and they have already started for 1.0). I have tried to get > a .1 release out in a timely manner, and then it seems patches for > stable become few and far between. In the 0.14 and 0.15 series, not > even enough to warrant a .2 release. Perhaps this is due to lack fixed > issues, or lack of effort to submit to stable. > 3) Security fixes do not follow this schedule, and will trigger a stable > release as needed. I would've thought that the usb-ccid CVE alone warrants a 0.15.2 of qemu and qemu-kvm. I am surprised nothing has happened there yet... http://patchwork.ozlabs.org/patch/128064/ Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Qemu stable releases
On Fri, Dec 09, 2011 at 10:39:37AM +, Richard W.M. Jones wrote: > FWIW in libguestfs we have such a policy. Every few weeks I evaluate > _all_ commits along the development branch and cherry pick those that > meet this policy back to the stable branch, followed by making a new > stable release. Here is the policy: > > http://libguestfs.org/guestfs.3.html#libguestfs_version_numbers > from "Our criteria for backporting changes are ..." For completeness, here is an example stable branch containing cherry-picked commits: http://fedorapeople.org/git/?p=rjones/public_git/libguestfs.git;a=log;h=refs/remotes/origin/stable-1.14 Compare to the master branch to see which commits did and didn't make it in. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
Re: [Qemu-devel] Qemu stable releases
On Mon, Dec 05, 2011 at 02:08:03PM -0600, Justin M. Forbes wrote: > The stable tree for 1.0 has now been created and the mailing list > exists. I am curious as to people's thoughts on how we should proceed. > There was discussion of setting up a predictable time table for stable > releases, say monthly or bimonthly, though that seems a bit difficult > from past experience. Typically I get a flurry of patches shortly after > a release (and they have already started for 1.0). I have tried to get > a .1 release out in a timely manner, and then it seems patches for > stable become few and far between. In the 0.14 and 0.15 series, not > even enough to warrant a .2 release. Perhaps this is due to lack fixed > issues, or lack of effort to submit to stable. What I would like to > recommend is the following: > > 1) On the 15th of every month, the stable queue will be evaluated for > release. > 2) If enough patches exist (or critical enough patches exist), a stable > release will be cut as soon as testing/push/mirror can be done. If > there are no patches, or not enough patches to warrant a release, they > will be held over until the next release. > 3) Security fixes do not follow this schedule, and will trigger a stable > release as needed. > > Questions, comments, concernes? How do people feel about this? Is there a policy for what commits count as stable? FWIW in libguestfs we have such a policy. Every few weeks I evaluate _all_ commits along the development branch and cherry pick those that meet this policy back to the stable branch, followed by making a new stable release. Here is the policy: http://libguestfs.org/guestfs.3.html#libguestfs_version_numbers from "Our criteria for backporting changes are ..." This is easy and has worked out well for us. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
Re: [Qemu-devel] Qemu stable releases
On Mon, Dec 5, 2011 at 8:08 PM, Justin M. Forbes wrote: > The stable tree for 1.0 has now been created and the mailing list > exists. Where does the stable 1.0 tree live? Stefan
[Qemu-devel] Qemu stable releases
The stable tree for 1.0 has now been created and the mailing list exists. I am curious as to people's thoughts on how we should proceed. There was discussion of setting up a predictable time table for stable releases, say monthly or bimonthly, though that seems a bit difficult from past experience. Typically I get a flurry of patches shortly after a release (and they have already started for 1.0). I have tried to get a .1 release out in a timely manner, and then it seems patches for stable become few and far between. In the 0.14 and 0.15 series, not even enough to warrant a .2 release. Perhaps this is due to lack fixed issues, or lack of effort to submit to stable. What I would like to recommend is the following: 1) On the 15th of every month, the stable queue will be evaluated for release. 2) If enough patches exist (or critical enough patches exist), a stable release will be cut as soon as testing/push/mirror can be done. If there are no patches, or not enough patches to warrant a release, they will be held over until the next release. 3) Security fixes do not follow this schedule, and will trigger a stable release as needed. Questions, comments, concernes? How do people feel about this? Justin
