Re: Where should the vhost-user specification live?

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Jun 10, 2026 at 09:03:39AM -0400, Stefan Hajnoczi wrote:
> On Tue, Jun 9, 2026 at 4:36 PM Michael S. Tsirkin <mst@redhat.com> 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 <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.
> 
> 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.

I'd be inclined to require non-trivial spec changes to have an
accompanying impl that is broadly feature complete, linked to by
the contributor as a pre-req for merge.

If an impl is not ready, then by all means send spec proposals
for the sake of design discussions. It can evolve in parallel
with the impl, but the spec doesn't need to merge until the impl
is broadly complete.

A code impl does not need to live in the same place as the spec
though.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|