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
next prev parent 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