Re: Where should the vhost-user specification live?

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

On Mon, Jun 01, 2026 at 11:18:15AM -0400, Stefan Hajnoczi wrote:
> On Mon, Jun 01, 2026 at 04:27:46PM +0200, Albert Esteve wrote:
> > On Mon, Jun 1, 2026 at 3:51 PM Stefan Hajnoczi <stefanha@gmail.com> wrote:
> > >
> > > On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > > > On Mon, Jun 1, 2026 at 2:39 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > >
> > > > > > On Mon, Jun 01, 2026 at 02:32:11PM +0200, Albert Esteve wrote:
> > > > > > >  But also because, in my opinion, separating
> > > > > > > the specification would improve development agility by decoupling
> > > > > > > specification development from QEMU's review and release cycles.
> > > > > >
> > > > > > Generally for QEMU this will be less agility, unless I misunderstand
> > > > > > what is proposed)
> > > > > >
> > > > > > Because presumably there will need to be spec releases then?
> > > > > >
> > > > > > So
> > > > > >         new feature -> spec tree -> spec release -> qemu implementation -> qemu release
> > > > > >
> > > > > > is surely longer that what we have now.
> > > > >
> > > > > I see your point.
> > > > >
> > > > > However, we do not really need to introduce a heavy release management
> > > > > layer. We could just operate it as a living document, where the main
> > > > > branch is the authoritative source of truth.
> > > > >
> > > > > For the workflow, development doesn't have to be strictly sequential
> > > > > either. A contributor can propose the spec update while working on the
> > > > > implementation, much like we do for VirtIO updates. Actually, this way
> > > > > one update/change supports the other.
> > > > >
> > > > > I guess my point is that a dedicated repository could lower the
> > > > > barrier for new changes AND keep QEMU's own development speed mostly
> > > > > unaffected.
> > > > >
> > > > > BR,
> > > > > Albert
> > > >
> > > > Something something submodule? Possibly. If you want to make progress
> > > > on this, pls think of the process, try it out.
> > >
> > > If I understand correctly, the motivation for moving the spec
> > > somewhere else is to replace the email patch review process with a git
> > > forge review process?
> > >
> > > This seems like a superficial change and is not worth in my opinion if
> > > you consider we'll have to redirect from the old spec location and
> > > move the community over to the new repo.
> > 
> > The core issue from my perspective is project neutrality and
> > decoupling lifecycles.
> >
> > Currently, protocol updates are tied to QEMU's tree rules and release
> > freezes for example. Since these changes also affect other projects
> > (like rust-vmm, crosvm, DPDK, etc.), separating them may make sense
> > and could streamline the process.
> 
> I don't see a reason to block vhost-user.rst changes during QEMU's
> freeze. If Michael sent a vhost-user spec pull request during freeze I
> would merge it.
> 
> > >We could actually lose spec
> > > change reviewers in the process either because they don't know what's
> > > going on or decide that they prefer to spend time elsewhere when faced
> > > with switching processes (the people who review and participate in
> > > discussion do so out of personal interest and as far as I'm aware no
> > > one is employed to work on vhost-user as their #1 priority).
> > 
> > This is a fair concern. I hope we maintain reviewer engagement. But it
> > could also be argued that contributors from other communities may be
> > more comfortable with a dedicated project-neutral home. It could well
> > go both ways, but it also represents an opportunity to grow.
> > 
> > >
> > > Having said that, here is what I imagine it would involve:
> > >
> > > 1. Michael creates a new repo on a git forge (if he wants it to be
> > > under the GitLab qemu-project organization I can help with creating
> > > the repo, otherwise he creates a new organization and repo).
> > > 2. Discussion happens in Issues.
> > > 3. Spec changes are proposed in Merge Requests. Michael merges them
> > > once consensus has been reached.
> > 
> > Mostly yes, though we wouldn't necessarily need Michael as the sole
> > gatekeeper. We could invite co-maintainers from other key projects to
> > share the reviewer load.
> >
> > Also I'd want to clarify that although I am advocating for this
> > change, I do not claim to have the definitive roadmap. I am just
> > sharing my view on why this could be a positive evolution. Consensus
> > may end up being to remain with the current status quo, or any of the
> > other options proposed by Alex.
> 
> I get a sense that this is about politics in the end. Do people feel
> they are not represented and would like to have more influence in the
> vhost-user spec?
> 
> You bring up project neutrality and a model where Michael is no longer
> the sole maintainer. It will be necessary to propose a concrete roadmap
> and also to explain the concerns about neutrality more so it's clear
> they won't be an issue anymore in the future system.
> 
> Why is the current system not neutral and how will the new system solve
> that?
> 
> Who should be a co-maintainer?
> 
> Stefan

And also, qemu currently acts like a reference implementation.
Which is something.

-- 
MST