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. > > > > Whether there will be more agility for non qemu users will depend on > > how often spec releases are cut. > > > > > > > > -- > > MST > >
