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