Re: Where should the vhost-user specification live?

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Jun 09, 2026 at 03:44:49PM -0400, Stefan Hajnoczi wrote:
> On Tue, Jun 9, 2026 at 2:51 PM Peter Maydell <peter.maydell@linaro.org> wrote:
> >
> > On Tue, 9 Jun 2026 at 19:00, Stefan Hajnoczi <stefanha@gmail.com> 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.

-- 
MST