[virtio-dev] Plans for releasing a VIRTIO 1.2 spec

[virtio-dev] Plans for releasing a VIRTIO 1.2 spec

[Cornelia Huck]

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).

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.

Please let us know if you have any concerns.

The VIRTIO TC Chairs


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

Re: [virtio-comment] Plans for releasing a VIRTIO 1.2 spec

[Christian Schoenebeck]

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.

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.

> 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?

> 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?

Best regards,
Christian Schoenebeck

[virtio] Re: [virtio-comment] Plans for releasing a VIRTIO 1.2 spec

[Cornelia Huck]

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 

[virtio] The virtio spec is now in FREEZE for 1.2

[Cornelia Huck]

The virtio spec is now in freeze for the upcoming 1.2 release.

What does this mean?
- No more issues will be accepted into the 1.2 release, i.e. no more
  votes will be started. Anything outstanding will be delayed until
  after we have released 1.2 (which we hope to have done by the end of
  March.)
- We may still do some editorial fixups.
- Behind the scenes, we will work on getting a Committee Specification
  Draft ready and out for review.

What does this NOT mean?
- No freeze on opening new issues, they will simply target the next
  release.
- Most certainly no freeze on discussions! Just keep in mind that the
  chairs/editors may be busy with other things.

We will update you on the progress along the way.


---------------------------------------------------------------------
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