On Tue, 9 Jun 2026 at 20:45, Stefan Hajnoczi <[email protected]> wrote: > > On Tue, Jun 9, 2026 at 2:51 PM Peter Maydell <[email protected]> wrote: > > > > On Tue, 9 Jun 2026 at 19:00, Stefan Hajnoczi <[email protected]> wrote: > > > I'm not sure if anyone brought up this topic on qemu-devel and with > > > Michael before. As I mentioned in my reply, there are ways to avoid > > > blocking vhost-user spec changes when qemu.git is frozen: > > > > > > The simplest approach is to keep merging vhost-user.rst changes during > > > freeze since it does not jeopardize the release or introduce > > > instability. > > > > I'm not enthusiastic about having "this one document is an > > exception to our freeze and release process". Because it is > > only documentation, it is in the same "we can be relatively > > relaxed about allowing in documentation changes" boat as > > most of the rest of the docs. But docs changes can break the > > build (e.g. if you mess up a rST syntax thing), so as we > > CI prevents broken rST from being merged (there are multiple jobs with > `--enable-docs`), so I'm not sure this can happen?
We've had oddball "only with some version of Sphinx" issues before. I agree it's not likely, which is why we're pretty lenient about letting in docs changes. But at the point where we get to "only really critical regression/bugfixes now", that includes "not docs changes either". > > get closer to the final release we are going to get more > > strict about "is this change really necessary or can it > > wait a few weeks?", and they must at a minimum continue to obey > > the "no changes of any kind between the last RC and the final > > release" rule. > > Why is the final release candidate special? Because we must make no changes between it and final release. Anything could be a cause of a regression; the week between last RC and release is there to catch any last minute problems, and if there are any then we would roll another RC and give it another week (or at least a few days) for that to be tested. We don't put in the regression fix and do the release without that extra RC cycle. This is the way we've run releases for the last decade; it's not a new rule. I tend to view the specs subsection of the docs as being for things where either QEMU really is the authoritative source (eg fw_cfg), or where the spec is for something that's basically moribund and has no better home. If vhost-user is a cross-project specification that it so active that it cannot live within QEMU's release process, then I think it deserves to have its own independent home. thanks -- PMM
