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 <[email protected]> wrote: > > > > > > On Mon, Jun 1, 2026 at 9:12 AM Michael S. Tsirkin <[email protected]> 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 <[email protected]> > > > > > 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
