Re: Where should the vhost-user specification live?

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

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.


Then maybe we can keep the email based review? Still the only
one with a decent offline capability.


> 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.
> 
> >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.

> >
> > It's similar to what we have now in qemu.git, except that a git forge is used.
> >
> > Stefan
> >