On Tue, Jun 9, 2026 at 4:36 PM Michael S. Tsirkin <[email protected]> wrote: > > On Tue, Jun 09, 2026 at 03:44:49PM -0400, Stefan Hajnoczi 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? > > > > > 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? > > > > > And definitely if a patchseries has both > > > QEMU code changes and documentation updates then that is > > > going to not get applied during freeze if the code changes > > > don't follow the freeze rules. > > > > I agree that code changes cannot be merged. > > > > As long as the vhost-user maintainer is confident that the spec change > > is implementable and stable, they can merge the spec change on its own > > without code changes. If they are not confident, then the spec change > > isn't ready to be merged yet. > > > > Stefan > > I personally have been confidently wrong enough times. Maybe others know > how to do better.
There is a risk with merging a spec change without a finished implementation, so no one can get it right every time. I bring this up because a clear guideline would help implementers know what to expect. Stefan
