Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>,
	virtio-comment@lists.oasis-open.org
Cc: virtio@lists.oasis-open.org, virtio-dev@lists.oasis-open.org,
	"Michael S. Tsirkin" <mst@redhat.com>
Subject: [virtio] Re: [virtio-comment] Plans for releasing a VIRTIO 1.2 spec
Date: Mon, 20 Dec 2021 16:02:05 +0100	[thread overview]
Message-ID: <87y24fpbf6.fsf@redhat.com> (raw)
In-Reply-To: <1716817.ojcOkzPiJ8@silver>

On Mon, Dec 20 2021, Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Montag, 20. Dezember 2021 13:47:03 CET Cornelia Huck wrote:
>> We are due (or rather overdue) for a new release of the VIRTIO spec. As
>> doing a release takes some time, we need to tie things up soon (remember
>> that there will also be a next revision for changes that don't make the
>> cut.)
>> 
>> We propose to declare a freeze on changes starting January 25th, 2022 (no
>> new non-editorial changes committed). This would mean that any ballot
>> needs to conclude on January 24th the latest (and therefore has to be
>> opened before January 17th). Any change that you want to see included in
>> 1.2 has to reach enough consensus to open a ballot in early January 2022.
>> 
>> Next steps would be creating a Comittee Specification Draft (and voting
>> on it), putting it out for review, and then creating (and voting on) a
>> Comittee Specification, hopefully before the end of March 2022.
>> 
>> To reiterate, anything that should be included in VIRTIO 1.2 needs to
>> have a ballot started
>> 
>>               *before January 17th, 2022*
>> 
>> at the very latest (preferably earlier).
>
> As holidays are starting this week, that realistically means a window of about 
> just one or two weeks, for both bringing a discussion eventually to its spec 
> commit, as well as concluding its subsequent ballot.

Yes, I realize that it seems short; however, we have to draw a line
somewhere...

>
> Maybe it's just me, but considering that the last virtio revision was 3 years 
> ago, that sounds like a sudden hammer fall to me.

...especially as we've dragged our feet for so long already, and we
really intend to put out a new spec release every year or so :(

>
>> This should give us enough time to tie up most proposals currently
>> actively discussed. Again, remember that anything that is late will
>> simply make it into the next release instead.
>
> Which will be when approximately?

I think our aim should be to release one spec per year (ISTR that we
also put that into the charter); so *hopefully* that would be in the
first quarter/half of 2023.

>
>> Please let us know if you have any concerns.
>> 
>> The VIRTIO TC Chairs
>
> Spec issues that won't make it through within this narrow time window would 
> not suffer under any negative consequences in form of reluctance for their 
> actual implementation patches on Linux kernel / QEMU side, would they?

For Linux/QEMU, I think we always operated under the assumption that a
commit in git is sufficient; IOW, for Linux/QEMU a new version of the
spec is not that important.

I am not sure if there are other projects out there that look only at
released versions. My impression was rather that most people were happy
enough once something seemed stable.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


  reply	other threads:[~2021-12-20 15:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-20 12:47 [virtio-dev] Plans for releasing a VIRTIO 1.2 spec Cornelia Huck
2021-12-20 14:04 ` [virtio-comment] " Christian Schoenebeck
2021-12-20 15:02   ` Cornelia Huck [this message]
2022-01-25 10:58 ` [virtio] The virtio spec is now in FREEZE for 1.2 Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y24fpbf6.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu_oss@crudebyte.com \
    --cc=virtio-comment@lists.oasis-open.org \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtio@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox