Re: Where should the vhost-user specification live?

--Gas364zqSwtfrver
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Michael S. Tsirkin <[email protected]=
om> wrote:
> > >
> > > On Mon, Jun 01, 2026 at 03:05:50PM +0200, Albert Esteve wrote:
> > > > On Mon, Jun 1, 2026 at 2:39=E2=80=AFPM Michael S. Tsirkin <mst@redh=
at.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 decoupli=
ng
> > > > > > specification development from QEMU's review and release cycles.
> > > > >
> > > > > Generally for QEMU this will be less agility, unless I misunderst=
and
> > > > > what is proposed)
> > > > >
> > > > > Because presumably there will need to be spec releases then?
> > > > >
> > > > > So
> > > > >         new feature -> spec tree -> spec release -> qemu implemen=
tation -> 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 managem=
ent
> > > > 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.
> >=20
> > 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?
>=20
> 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

--Gas364zqSwtfrver
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmodujAACgkQnKSrs4Gr
c8iMnAf9FhEItYatirGCRYlUNMtMnIJh1WEgBLyVx4ky+bk7z8ymjwkelgdzS3al
kjlqNgY8W0r8acJQfpLCFWC8Sn7gpDvlVV8761wskleBkCUk19DM5HHYpG/8e7bZ
bggBp9QsfuumCelE5rx4ePa8ria9EmxChbMyQ1fy1318FK8tI8omZddUvX9RrvQg
tkYu9svT9hGeul5H2KlhvpS2HHdbCs6CvpSckp04/gP+dDvCdOr+Qwn8FKGOkNMx
gz8GHZMlKuBuFj/di3CFc1yaXposopIjNl0bDZ4p7/o8vT3/7D+rgiY+EyEku5ox
oVW1egvEDYlKV3JLDUN+M9GkYyhqpQ==
=y53Q
-----END PGP SIGNATURE-----

--Gas364zqSwtfrver--