On Mon, Jun 01, 2026 at 10:22:32AM -0400, Michael S. Tsirkin wrote: > On Mon, Jun 01, 2026 at 09:51:40AM -0400, Stefan Hajnoczi 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? > > wait who said that?
I thought that's what the issue ultimately comes down to but it's clear now that's not it. Stefan
signature.asc
Description: PGP signature
