OASIS Virtual I/O Device (VIRTIO) TC

The virtio 1.2 spec has been released on July 1st, 2022, so I think we should come up with a plan for the 1.3 release. Given that it took us several months last time, we need to think about declaring freeze during (northern hemisphere) summer if we want to have a release ready before the end-of-year holiday season starts. We have some things currently under discussion/review that we should still consider for 1.3: - vq index etc. naming cleanup - admin vq - virtio-video - some things we deferred for 1.2 (see https://github.com/oasis-tcs/virtio-spec/issues?q=is%3Aissue+is%3Aopen+label%3Adeferred-in-v1.2-csprd01 ) - other things that are not on my personal list (please mention whatever you think is important) Please also keep in mind that 1.3 will not be the last virtio release, and many projects like Linux or QEMU consider features stable and ready for inclusion once the spec has hit the git tree, but not neccessarily a virtio spec release. That said, let me propose the following timeline: - July 1st 2023: enter feature freeze; all proposed changes must at least have an open github issue that refers to a proposal on-list - August 1st 2023: enter change freeze; everything needs to have been voted upon (i.e. we can start with preparations for a release like compiling the change log) - at the same time, fork virtio-next, which can be used for development while we're working on the release - August/September 2023: prepare draft, initiate initial voting etc. - by September/October 2023: have the final 1.3 spec ready, voted upon, and released - virtio-next can be merged into mainline, and we continue with business as usual Thoughts? We might want to move things a tad earlier, but I don't think we should push the schedule out much further.

Hi Cornelia,

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Cornelia Huck
> Sent: Wednesday, April 5, 2023 9:57 AM
>
> The virtio 1.2 spec has been released on July 1st, 2022, so I think we should
> come up with a plan for the 1.3 release. Given that it took us several months
> last time, we need to think about declaring freeze during (northern
> hemisphere) summer if we want to have a release ready before the end-of-
> year holiday season starts.
>
> We have some things currently under discussion/review that we should still
> consider for 1.3:
>
> - vq index etc. naming cleanup
> - admin vq
> - virtio-video
> - some things we deferred for 1.2 (see
> https://github.com/oasis-tcs/virtio-
> spec/issues?q=is%3Aissue+is%3Aopen+label%3Adeferred-in-v1.2-csprd01)
> - other things that are not on my personal list (please mention whatever
> you think is important)
>
Please included transitional VF device support to the list whose proposal is already in progress.
It has matching github issue.

Hi Cornelia,

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Cornelia Huck
> Sent: Wednesday, April 5, 2023 9:57 AM
>
> The virtio 1.2 spec has been released on July 1st, 2022, so I think we should
> come up with a plan for the 1.3 release. Given that it took us several months
> last time, we need to think about declaring freeze during (northern
> hemisphere) summer if we want to have a release ready before the end-of-
> year holiday season starts.
>
> We have some things currently under discussion/review that we should still
> consider for 1.3:
>
> - vq index etc. naming cleanup
> - admin vq
> - virtio-video
> - some things we deferred for 1.2 (see
> https://github.com/oasis-tcs/virtio-
> spec/issues?q=is%3Aissue+is%3Aopen+label%3Adeferred-in-v1.2-csprd01)
> - other things that are not on my personal list (please mention whatever
> you think is important)
>
Please included transitional VF device support to the list whose proposal is already in progress.
It has matching github issue.

Hi Cornelia, > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- > open.org> On Behalf Of Cornelia Huck > Sent: Wednesday, April 5, 2023 9:57 AM > > The virtio 1.2 spec has been released on July 1st, 2022, so I think we should > come up with a plan for the 1.3 release. Given that it took us several months > last time, we need to think about declaring freeze during (northern > hemisphere) summer if we want to have a release ready before the end-of- > year holiday season starts. > > We have some things currently under discussion/review that we should still > consider for 1.3: > > - vq index etc. naming cleanup > - admin vq > - virtio-video > - some things we deferred for 1.2 (see > https://github.com/oasis-tcs/virtio- > spec/issues?q=is%3Aissue+is%3Aopen+label%3Adeferred-in-v1.2-csprd01) > - other things that are not on my personal list (please mention whatever > you think is important) > Please included transitional VF device support to the list whose proposal is already in progress. It has matching github issue.

On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote:
> That said, let me propose the following timeline:
>
> - July 1st 2023: enter feature freeze; all proposed changes must at
> least have an open github issue that refers to a proposal on-list
> - August 1st 2023: enter change freeze; everything needs to have been
> voted upon (i.e. we can start with preparations for a release like
> compiling the change log)
> - at the same time, fork virtio-next, which can be used for development
> while we're working on the release
> - August/September 2023: prepare draft, initiate initial voting etc.
> - by September/October 2023: have the final 1.3 spec ready, voted upon,
> and released
> - virtio-next can be merged into mainline, and we continue with business
> as usual
>
> Thoughts? We might want to move things a tad earlier, but I don't think
> we should push the schedule out much further.

Sounds good to me. If the date is earlier then it will be necessary to
scrutinize the list of features for 1.3 and think hard about which ones
fit, but freezing on July 1st sounds realistic to me.

Stefan

On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote:
> That said, let me propose the following timeline:
>
> - July 1st 2023: enter feature freeze; all proposed changes must at
> least have an open github issue that refers to a proposal on-list
> - August 1st 2023: enter change freeze; everything needs to have been
> voted upon (i.e. we can start with preparations for a release like
> compiling the change log)
> - at the same time, fork virtio-next, which can be used for development
> while we're working on the release
> - August/September 2023: prepare draft, initiate initial voting etc.
> - by September/October 2023: have the final 1.3 spec ready, voted upon,
> and released
> - virtio-next can be merged into mainline, and we continue with business
> as usual
>
> Thoughts? We might want to move things a tad earlier, but I don't think
> we should push the schedule out much further.

Sounds good to me. If the date is earlier then it will be necessary to
scrutinize the list of features for 1.3 and think hard about which ones
fit, but freezing on July 1st sounds realistic to me.

Stefan

On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote: > That said, let me propose the following timeline: > > - July 1st 2023: enter feature freeze; all proposed changes must at > least have an open github issue that refers to a proposal on-list > - August 1st 2023: enter change freeze; everything needs to have been > voted upon (i.e. we can start with preparations for a release like > compiling the change log) > - at the same time, fork virtio-next, which can be used for development > while we're working on the release > - August/September 2023: prepare draft, initiate initial voting etc. > - by September/October 2023: have the final 1.3 spec ready, voted upon, > and released > - virtio-next can be merged into mainline, and we continue with business > as usual > > Thoughts? We might want to move things a tad earlier, but I don't think > we should push the schedule out much further. Sounds good to me. If the date is earlier then it will be necessary to scrutinize the list of features for 1.3 and think hard about which ones fit, but freezing on July 1st sounds realistic to me. Stefan Attachment: signature.asc Description: PGP signature

On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote:
> The virtio 1.2 spec has been released on July 1st, 2022, so I think we
> should come up with a plan for the 1.3 release. Given that it took us
> several months last time, we need to think about declaring freeze during
> (northern hemisphere) summer if we want to have a release ready before
> the end-of-year holiday season starts.
>
> We have some things currently under discussion/review that we should
> still consider for 1.3:
>
> - vq index etc. naming cleanup
> - admin vq
> - virtio-video
> - some things we deferred for 1.2 (see
> https://github.com/oasis-tcs/virtio-spec/issues?q=is%3Aissue+is%3Aopen+label%3Adeferred-in-v1.2-csprd01)
> - other things that are not on my personal list (please mention whatever
> you think is important)
>
> Please also keep in mind that 1.3 will not be the last virtio release,
> and many projects like Linux or QEMU consider features stable and ready
> for inclusion once the spec has hit the git tree, but not neccessarily a
> virtio spec release.
>
> That said, let me propose the following timeline:
>
> - July 1st 2023: enter feature freeze; all proposed changes must at
> least have an open github issue that refers to a proposal on-list
> - August 1st 2023: enter change freeze; everything needs to have been
> voted upon (i.e. we can start with preparations for a release like
> compiling the change log)
> - at the same time, fork virtio-next, which can be used for development
> while we're working on the release
> - August/September 2023: prepare draft, initiate initial voting etc.

Hmm looks like you forgot a 30 day the public review period (or is that
included in the "etc"? ). During this period we will likely receive
review comments which we have to address. Should the changes turn out to
be material, another public review period will be required.
Let's spell it out please.



> - by September/October 2023: have the final 1.3 spec ready, voted upon,
> and released
> - virtio-next can be merged into mainline, and we continue with business
> as usual
>
> Thoughts? We might want to move things a tad earlier, but I don't think
> we should push the schedule out much further.

On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote:
> The virtio 1.2 spec has been released on July 1st, 2022, so I think we
> should come up with a plan for the 1.3 release. Given that it took us
> several months last time, we need to think about declaring freeze during
> (northern hemisphere) summer if we want to have a release ready before
> the end-of-year holiday season starts.
>
> We have some things currently under discussion/review that we should
> still consider for 1.3:
>
> - vq index etc. naming cleanup
> - admin vq
> - virtio-video
> - some things we deferred for 1.2 (see
> https://github.com/oasis-tcs/virtio-spec/issues?q=is%3Aissue+is%3Aopen+label%3Adeferred-in-v1.2-csprd01)
> - other things that are not on my personal list (please mention whatever
> you think is important)
>
> Please also keep in mind that 1.3 will not be the last virtio release,
> and many projects like Linux or QEMU consider features stable and ready
> for inclusion once the spec has hit the git tree, but not neccessarily a
> virtio spec release.
>
> That said, let me propose the following timeline:
>
> - July 1st 2023: enter feature freeze; all proposed changes must at
> least have an open github issue that refers to a proposal on-list
> - August 1st 2023: enter change freeze; everything needs to have been
> voted upon (i.e. we can start with preparations for a release like
> compiling the change log)
> - at the same time, fork virtio-next, which can be used for development
> while we're working on the release
> - August/September 2023: prepare draft, initiate initial voting etc.

Hmm looks like you forgot a 30 day the public review period (or is that
included in the "etc"? ). During this period we will likely receive
review comments which we have to address. Should the changes turn out to
be material, another public review period will be required.
Let's spell it out please.



> - by September/October 2023: have the final 1.3 spec ready, voted upon,
> and released
> - virtio-next can be merged into mainline, and we continue with business
> as usual
>
> Thoughts? We might want to move things a tad earlier, but I don't think
> we should push the schedule out much further.

On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote: > The virtio 1.2 spec has been released on July 1st, 2022, so I think we > should come up with a plan for the 1.3 release. Given that it took us > several months last time, we need to think about declaring freeze during > (northern hemisphere) summer if we want to have a release ready before > the end-of-year holiday season starts. > > We have some things currently under discussion/review that we should > still consider for 1.3: > > - vq index etc. naming cleanup > - admin vq > - virtio-video > - some things we deferred for 1.2 (see > https://github.com/oasis-tcs/virtio-spec/issues?q=is%3Aissue+is%3Aopen+label%3Adeferred-in-v1.2-csprd01 ) > - other things that are not on my personal list (please mention whatever > you think is important) > > Please also keep in mind that 1.3 will not be the last virtio release, > and many projects like Linux or QEMU consider features stable and ready > for inclusion once the spec has hit the git tree, but not neccessarily a > virtio spec release. > > That said, let me propose the following timeline: > > - July 1st 2023: enter feature freeze; all proposed changes must at > least have an open github issue that refers to a proposal on-list > - August 1st 2023: enter change freeze; everything needs to have been > voted upon (i.e. we can start with preparations for a release like > compiling the change log) > - at the same time, fork virtio-next, which can be used for development > while we're working on the release > - August/September 2023: prepare draft, initiate initial voting etc. Hmm looks like you forgot a 30 day the public review period (or is that included in the "etc"? ). During this period we will likely receive review comments which we have to address. Should the changes turn out to be material, another public review period will be required. Let's spell it out please. > - by September/October 2023: have the final 1.3 spec ready, voted upon, > and released > - virtio-next can be merged into mainline, and we continue with business > as usual > > Thoughts? We might want to move things a tad earlier, but I don't think > we should push the schedule out much further.

On Fri, Apr 07 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote:
>> That said, let me propose the following timeline:
>>
>> - July 1st 2023: enter feature freeze; all proposed changes must at
>> least have an open github issue that refers to a proposal on-list
>> - August 1st 2023: enter change freeze; everything needs to have been
>> voted upon (i.e. we can start with preparations for a release like
>> compiling the change log)
>> - at the same time, fork virtio-next, which can be used for development
>> while we're working on the release
>> - August/September 2023: prepare draft, initiate initial voting etc.
>
> Hmm looks like you forgot a 30 day the public review period (or is that
> included in the "etc"? ). During this period we will likely receive
> review comments which we have to address. Should the changes turn out to
> be material, another public review period will be required.
> Let's spell it out please.

Yeah, that's what I meant with "etc"... let's make this:

- August 2023: prepare draft, aim to have it ready and voted upon by
August 31 the latest (preferrably earlier)
- September 2023: public review period (30 days)
- October 2023: another public review period, if needed; otherwise, get
comittee specification ready and voted upon
- October (maybe November, if we're running late) 2023: virtio 1.3
released

The most important dates are feature freeze on Jul 1 and change freeze
on Aug 1, I guess; for the rest, we depend on whether people are out on
PTO, which kind of feedback we get, etc. -- but as long as we release
1.3 in 2023, I'll be happy enough.

>
>
>
>> - by September/October 2023: have the final 1.3 spec ready, voted upon,
>> and released
>> - virtio-next can be merged into mainline, and we continue with business
>> as usual
>>
>> Thoughts? We might want to move things a tad earlier, but I don't think
>> we should push the schedule out much further.

On Fri, Apr 07 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote:
>> That said, let me propose the following timeline:
>>
>> - July 1st 2023: enter feature freeze; all proposed changes must at
>> least have an open github issue that refers to a proposal on-list
>> - August 1st 2023: enter change freeze; everything needs to have been
>> voted upon (i.e. we can start with preparations for a release like
>> compiling the change log)
>> - at the same time, fork virtio-next, which can be used for development
>> while we're working on the release
>> - August/September 2023: prepare draft, initiate initial voting etc.
>
> Hmm looks like you forgot a 30 day the public review period (or is that
> included in the "etc"? ). During this period we will likely receive
> review comments which we have to address. Should the changes turn out to
> be material, another public review period will be required.
> Let's spell it out please.

Yeah, that's what I meant with "etc"... let's make this:

- August 2023: prepare draft, aim to have it ready and voted upon by
August 31 the latest (preferrably earlier)
- September 2023: public review period (30 days)
- October 2023: another public review period, if needed; otherwise, get
comittee specification ready and voted upon
- October (maybe November, if we're running late) 2023: virtio 1.3
released

The most important dates are feature freeze on Jul 1 and change freeze
on Aug 1, I guess; for the rest, we depend on whether people are out on
PTO, which kind of feedback we get, etc. -- but as long as we release
1.3 in 2023, I'll be happy enough.

>
>
>
>> - by September/October 2023: have the final 1.3 spec ready, voted upon,
>> and released
>> - virtio-next can be merged into mainline, and we continue with business
>> as usual
>>
>> Thoughts? We might want to move things a tad earlier, but I don't think
>> we should push the schedule out much further.

On Fri, Apr 07 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Wed, Apr 05, 2023 at 03:57:09PM +0200, Cornelia Huck wrote: >> That said, let me propose the following timeline: >> >> - July 1st 2023: enter feature freeze; all proposed changes must at >> least have an open github issue that refers to a proposal on-list >> - August 1st 2023: enter change freeze; everything needs to have been >> voted upon (i.e. we can start with preparations for a release like >> compiling the change log) >> - at the same time, fork virtio-next, which can be used for development >> while we're working on the release >> - August/September 2023: prepare draft, initiate initial voting etc. > > Hmm looks like you forgot a 30 day the public review period (or is that > included in the "etc"? ). During this period we will likely receive > review comments which we have to address. Should the changes turn out to > be material, another public review period will be required. > Let's spell it out please. Yeah, that's what I meant with "etc"... let's make this: - August 2023: prepare draft, aim to have it ready and voted upon by August 31 the latest (preferrably earlier) - September 2023: public review period (30 days) - October 2023: another public review period, if needed; otherwise, get comittee specification ready and voted upon - October (maybe November, if we're running late) 2023: virtio 1.3 released The most important dates are feature freeze on Jul 1 and change freeze on Aug 1, I guess; for the rest, we depend on whether people are out on PTO, which kind of feedback we get, etc. -- but as long as we release 1.3 in 2023, I'll be happy enough. > > > >> - by September/October 2023: have the final 1.3 spec ready, voted upon, >> and released >> - virtio-next can be merged into mainline, and we continue with business >> as usual >> >> Thoughts? We might want to move things a tad earlier, but I don't think >> we should push the schedule out much further.

Hi Cornelia, Michael,

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Cornelia Huck
> Sent: Wednesday, April 12, 2023 12:17 PM

> >> - July 1st 2023: enter feature freeze; all proposed changes must at
> >> least have an open github issue that refers to a proposal on-list
> >> - August 1st 2023: enter change freeze; everything needs to have been
> >> voted upon (i.e. we can start with preparations for a release like
> >> compiling the change log)
> >> - at the same time, fork virtio-next, which can be used for development
> >> while we're working on the release
> >> - August/September 2023: prepare draft, initiate initial voting etc.
> >
> > Hmm looks like you forgot a 30 day the public review period (or is
> > that included in the "etc"? ). During this period we will likely
> > receive review comments which we have to address. Should the changes
> > turn out to be material, another public review period will be required.
> > Let's spell it out please.
>
> Yeah, that's what I meant with "etc"... let's make this:
>
> - August 2023: prepare draft, aim to have it ready and voted upon by
> August 31 the latest (preferrably earlier)
> - September 2023: public review period (30 days)
> - October 2023: another public review period, if needed; otherwise, get
> comittee specification ready and voted upon
> - October (maybe November, if we're running late) 2023: virtio 1.3
> released
>
> The most important dates are feature freeze on Jul 1 and change freeze on Aug
> 1, I guess; for the rest, we depend on whether people are out on PTO, which
> kind of feedback we get, etc. -- but as long as we release
> 1.3 in 2023, I'll be happy enough.

We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)

1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
[1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html

2. first user of aq for legacy access at v7.
2 patches. First 2 are Fixes.
[2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html

Both need few more days of review and vote.
Shall we please have few days in July for them so that it can be part of 1.3?
or whole July is needed to prepare the draft spec?

Hi Cornelia, Michael,

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Cornelia Huck
> Sent: Wednesday, April 12, 2023 12:17 PM

> >> - July 1st 2023: enter feature freeze; all proposed changes must at
> >> least have an open github issue that refers to a proposal on-list
> >> - August 1st 2023: enter change freeze; everything needs to have been
> >> voted upon (i.e. we can start with preparations for a release like
> >> compiling the change log)
> >> - at the same time, fork virtio-next, which can be used for development
> >> while we're working on the release
> >> - August/September 2023: prepare draft, initiate initial voting etc.
> >
> > Hmm looks like you forgot a 30 day the public review period (or is
> > that included in the "etc"? ). During this period we will likely
> > receive review comments which we have to address. Should the changes
> > turn out to be material, another public review period will be required.
> > Let's spell it out please.
>
> Yeah, that's what I meant with "etc"... let's make this:
>
> - August 2023: prepare draft, aim to have it ready and voted upon by
> August 31 the latest (preferrably earlier)
> - September 2023: public review period (30 days)
> - October 2023: another public review period, if needed; otherwise, get
> comittee specification ready and voted upon
> - October (maybe November, if we're running late) 2023: virtio 1.3
> released
>
> The most important dates are feature freeze on Jul 1 and change freeze on Aug
> 1, I guess; for the rest, we depend on whether people are out on PTO, which
> kind of feedback we get, etc. -- but as long as we release
> 1.3 in 2023, I'll be happy enough.

We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)

1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
[1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html

2. first user of aq for legacy access at v7.
2 patches. First 2 are Fixes.
[2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html

Both need few more days of review and vote.
Shall we please have few days in July for them so that it can be part of 1.3?
or whole July is needed to prepare the draft spec?

Hi Cornelia, Michael, > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- > open.org> On Behalf Of Cornelia Huck > Sent: Wednesday, April 12, 2023 12:17 PM > >> - July 1st 2023: enter feature freeze; all proposed changes must at > >> least have an open github issue that refers to a proposal on-list > >> - August 1st 2023: enter change freeze; everything needs to have been > >> voted upon (i.e. we can start with preparations for a release like > >> compiling the change log) > >> - at the same time, fork virtio-next, which can be used for development > >> while we're working on the release > >> - August/September 2023: prepare draft, initiate initial voting etc. > > > > Hmm looks like you forgot a 30 day the public review period (or is > > that included in the "etc"? ). During this period we will likely > > receive review comments which we have to address. Should the changes > > turn out to be material, another public review period will be required. > > Let's spell it out please. > > Yeah, that's what I meant with "etc"... let's make this: > > - August 2023: prepare draft, aim to have it ready and voted upon by > August 31 the latest (preferrably earlier) > - September 2023: public review period (30 days) > - October 2023: another public review period, if needed; otherwise, get > comittee specification ready and voted upon > - October (maybe November, if we're running late) 2023: virtio 1.3 > released > > The most important dates are feature freeze on Jul 1 and change freeze on Aug > 1, I guess; for the rest, we depend on whether people are out on PTO, which > kind of feedback we get, etc. -- but as long as we release > 1.3 in 2023, I'll be happy enough. We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :) 1. inner hash v19, rolling to v20 anytime this week. 1 Patch. [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html 2. first user of aq for legacy access at v7. 2 patches. First 2 are Fixes. [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html Both need few more days of review and vote. Shall we please have few days in July for them so that it can be part of 1.3? or whole July is needed to prepare the draft spec?

On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote:
> Hi Cornelia, Michael,
>
> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> > open.org> On Behalf Of Cornelia Huck
> > Sent: Wednesday, April 12, 2023 12:17 PM
>
> > >> - July 1st 2023: enter feature freeze; all proposed changes must at
> > >> least have an open github issue that refers to a proposal on-list
> > >> - August 1st 2023: enter change freeze; everything needs to have been
> > >> voted upon (i.e. we can start with preparations for a release like
> > >> compiling the change log)
> > >> - at the same time, fork virtio-next, which can be used for development
> > >> while we're working on the release
> > >> - August/September 2023: prepare draft, initiate initial voting etc.
> > >
> > > Hmm looks like you forgot a 30 day the public review period (or is
> > > that included in the "etc"? ). During this period we will likely
> > > receive review comments which we have to address. Should the changes
> > > turn out to be material, another public review period will be required.
> > > Let's spell it out please.
> >
> > Yeah, that's what I meant with "etc"... let's make this:
> >
> > - August 2023: prepare draft, aim to have it ready and voted upon by
> > August 31 the latest (preferrably earlier)
> > - September 2023: public review period (30 days)
> > - October 2023: another public review period, if needed; otherwise, get
> > comittee specification ready and voted upon
> > - October (maybe November, if we're running late) 2023: virtio 1.3
> > released
> >
> > The most important dates are feature freeze on Jul 1 and change freeze on Aug
> > 1, I guess; for the rest, we depend on whether people are out on PTO, which
> > kind of feedback we get, etc. -- but as long as we release
> > 1.3 in 2023, I'll be happy enough.
>
> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)
>
> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html
>
> 2. first user of aq for legacy access at v7.
> 2 patches. First 2 are Fixes.
> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html
>
> Both need few more days of review and vote.
> Shall we please have few days in July for them so that it can be part of 1.3?
> or whole July is needed to prepare the draft spec?

I think it's not too bad, projects that do releases every couple of
months can afford to be strict, we do them ones a year and a half
it makes sense to be flexible.

--
MST

On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote:
> Hi Cornelia, Michael,
>
> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> > open.org> On Behalf Of Cornelia Huck
> > Sent: Wednesday, April 12, 2023 12:17 PM
>
> > >> - July 1st 2023: enter feature freeze; all proposed changes must at
> > >> least have an open github issue that refers to a proposal on-list
> > >> - August 1st 2023: enter change freeze; everything needs to have been
> > >> voted upon (i.e. we can start with preparations for a release like
> > >> compiling the change log)
> > >> - at the same time, fork virtio-next, which can be used for development
> > >> while we're working on the release
> > >> - August/September 2023: prepare draft, initiate initial voting etc.
> > >
> > > Hmm looks like you forgot a 30 day the public review period (or is
> > > that included in the "etc"? ). During this period we will likely
> > > receive review comments which we have to address. Should the changes
> > > turn out to be material, another public review period will be required.
> > > Let's spell it out please.
> >
> > Yeah, that's what I meant with "etc"... let's make this:
> >
> > - August 2023: prepare draft, aim to have it ready and voted upon by
> > August 31 the latest (preferrably earlier)
> > - September 2023: public review period (30 days)
> > - October 2023: another public review period, if needed; otherwise, get
> > comittee specification ready and voted upon
> > - October (maybe November, if we're running late) 2023: virtio 1.3
> > released
> >
> > The most important dates are feature freeze on Jul 1 and change freeze on Aug
> > 1, I guess; for the rest, we depend on whether people are out on PTO, which
> > kind of feedback we get, etc. -- but as long as we release
> > 1.3 in 2023, I'll be happy enough.
>
> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)
>
> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html
>
> 2. first user of aq for legacy access at v7.
> 2 patches. First 2 are Fixes.
> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html
>
> Both need few more days of review and vote.
> Shall we please have few days in July for them so that it can be part of 1.3?
> or whole July is needed to prepare the draft spec?

I think it's not too bad, projects that do releases every couple of
months can afford to be strict, we do them ones a year and a half
it makes sense to be flexible.

--
MST

On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote: > Hi Cornelia, Michael, > > > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- > > open.org> On Behalf Of Cornelia Huck > > Sent: Wednesday, April 12, 2023 12:17 PM > > > >> - July 1st 2023: enter feature freeze; all proposed changes must at > > >> least have an open github issue that refers to a proposal on-list > > >> - August 1st 2023: enter change freeze; everything needs to have been > > >> voted upon (i.e. we can start with preparations for a release like > > >> compiling the change log) > > >> - at the same time, fork virtio-next, which can be used for development > > >> while we're working on the release > > >> - August/September 2023: prepare draft, initiate initial voting etc. > > > > > > Hmm looks like you forgot a 30 day the public review period (or is > > > that included in the "etc"? ). During this period we will likely > > > receive review comments which we have to address. Should the changes > > > turn out to be material, another public review period will be required. > > > Let's spell it out please. > > > > Yeah, that's what I meant with "etc"... let's make this: > > > > - August 2023: prepare draft, aim to have it ready and voted upon by > > August 31 the latest (preferrably earlier) > > - September 2023: public review period (30 days) > > - October 2023: another public review period, if needed; otherwise, get > > comittee specification ready and voted upon > > - October (maybe November, if we're running late) 2023: virtio 1.3 > > released > > > > The most important dates are feature freeze on Jul 1 and change freeze on Aug > > 1, I guess; for the rest, we depend on whether people are out on PTO, which > > kind of feedback we get, etc. -- but as long as we release > > 1.3 in 2023, I'll be happy enough. > > We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :) > > 1. inner hash v19, rolling to v20 anytime this week. 1 Patch. > [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html > > 2. first user of aq for legacy access at v7. > 2 patches. First 2 are Fixes. > [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html > > Both need few more days of review and vote. > Shall we please have few days in July for them so that it can be part of 1.3? > or whole July is needed to prepare the draft spec? I think it's not too bad, projects that do releases every couple of months can afford to be strict, we do them ones a year and a half it makes sense to be flexible. -- MST

On Thu, Jun 29 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote:
>> Hi Cornelia, Michael,
>>
>> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
>> > open.org> On Behalf Of Cornelia Huck
>> > Sent: Wednesday, April 12, 2023 12:17 PM
>>
>> > >> - July 1st 2023: enter feature freeze; all proposed changes must at
>> > >> least have an open github issue that refers to a proposal on-list
>> > >> - August 1st 2023: enter change freeze; everything needs to have been
>> > >> voted upon (i.e. we can start with preparations for a release like
>> > >> compiling the change log)
>> > >> - at the same time, fork virtio-next, which can be used for development
>> > >> while we're working on the release
>> > >> - August/September 2023: prepare draft, initiate initial voting etc.
>> > >
>> > > Hmm looks like you forgot a 30 day the public review period (or is
>> > > that included in the "etc"? ). During this period we will likely
>> > > receive review comments which we have to address. Should the changes
>> > > turn out to be material, another public review period will be required.
>> > > Let's spell it out please.
>> >
>> > Yeah, that's what I meant with "etc"... let's make this:
>> >
>> > - August 2023: prepare draft, aim to have it ready and voted upon by
>> > August 31 the latest (preferrably earlier)
>> > - September 2023: public review period (30 days)
>> > - October 2023: another public review period, if needed; otherwise, get
>> > comittee specification ready and voted upon
>> > - October (maybe November, if we're running late) 2023: virtio 1.3
>> > released
>> >
>> > The most important dates are feature freeze on Jul 1 and change freeze on Aug
>> > 1, I guess; for the rest, we depend on whether people are out on PTO, which
>> > kind of feedback we get, etc. -- but as long as we release
>> > 1.3 in 2023, I'll be happy enough.
>>
>> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)
>>
>> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
>> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html
>>
>> 2. first user of aq for legacy access at v7.
>> 2 patches. First 2 are Fixes.
>> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html
>>
>> Both need few more days of review and vote.
>> Shall we please have few days in July for them so that it can be part of 1.3?
>> or whole July is needed to prepare the draft spec?
>
> I think it's not too bad, projects that do releases every couple of
> months can afford to be strict, we do them ones a year and a half
> it makes sense to be flexible.

Yes, my only concern is to avoid slipping too badly -- and the "feature
freeze" period was actually intended to give us some time to wrap up
outstanding features.

For the inner header hash, I see there's already an issue (#173), so
it's good. I have not followed the aq legacy access feature -- if
everyone agrees that we should be able to vote on it in July, we should
have an issue for it as well (I cannot find one just by looking at
titles.)

Any other features that people are aware of?

On Thu, Jun 29 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote:
>> Hi Cornelia, Michael,
>>
>> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
>> > open.org> On Behalf Of Cornelia Huck
>> > Sent: Wednesday, April 12, 2023 12:17 PM
>>
>> > >> - July 1st 2023: enter feature freeze; all proposed changes must at
>> > >> least have an open github issue that refers to a proposal on-list
>> > >> - August 1st 2023: enter change freeze; everything needs to have been
>> > >> voted upon (i.e. we can start with preparations for a release like
>> > >> compiling the change log)
>> > >> - at the same time, fork virtio-next, which can be used for development
>> > >> while we're working on the release
>> > >> - August/September 2023: prepare draft, initiate initial voting etc.
>> > >
>> > > Hmm looks like you forgot a 30 day the public review period (or is
>> > > that included in the "etc"? ). During this period we will likely
>> > > receive review comments which we have to address. Should the changes
>> > > turn out to be material, another public review period will be required.
>> > > Let's spell it out please.
>> >
>> > Yeah, that's what I meant with "etc"... let's make this:
>> >
>> > - August 2023: prepare draft, aim to have it ready and voted upon by
>> > August 31 the latest (preferrably earlier)
>> > - September 2023: public review period (30 days)
>> > - October 2023: another public review period, if needed; otherwise, get
>> > comittee specification ready and voted upon
>> > - October (maybe November, if we're running late) 2023: virtio 1.3
>> > released
>> >
>> > The most important dates are feature freeze on Jul 1 and change freeze on Aug
>> > 1, I guess; for the rest, we depend on whether people are out on PTO, which
>> > kind of feedback we get, etc. -- but as long as we release
>> > 1.3 in 2023, I'll be happy enough.
>>
>> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)
>>
>> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
>> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html
>>
>> 2. first user of aq for legacy access at v7.
>> 2 patches. First 2 are Fixes.
>> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html
>>
>> Both need few more days of review and vote.
>> Shall we please have few days in July for them so that it can be part of 1.3?
>> or whole July is needed to prepare the draft spec?
>
> I think it's not too bad, projects that do releases every couple of
> months can afford to be strict, we do them ones a year and a half
> it makes sense to be flexible.

Yes, my only concern is to avoid slipping too badly -- and the "feature
freeze" period was actually intended to give us some time to wrap up
outstanding features.

For the inner header hash, I see there's already an issue (#173), so
it's good. I have not followed the aq legacy access feature -- if
everyone agrees that we should be able to vote on it in July, we should
have an issue for it as well (I cannot find one just by looking at
titles.)

Any other features that people are aware of?

On Thu, Jun 29 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote: > On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote: >> Hi Cornelia, Michael, >> >> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- >> > open.org> On Behalf Of Cornelia Huck >> > Sent: Wednesday, April 12, 2023 12:17 PM >> >> > >> - July 1st 2023: enter feature freeze; all proposed changes must at >> > >> least have an open github issue that refers to a proposal on-list >> > >> - August 1st 2023: enter change freeze; everything needs to have been >> > >> voted upon (i.e. we can start with preparations for a release like >> > >> compiling the change log) >> > >> - at the same time, fork virtio-next, which can be used for development >> > >> while we're working on the release >> > >> - August/September 2023: prepare draft, initiate initial voting etc. >> > > >> > > Hmm looks like you forgot a 30 day the public review period (or is >> > > that included in the "etc"? ). During this period we will likely >> > > receive review comments which we have to address. Should the changes >> > > turn out to be material, another public review period will be required. >> > > Let's spell it out please. >> > >> > Yeah, that's what I meant with "etc"... let's make this: >> > >> > - August 2023: prepare draft, aim to have it ready and voted upon by >> > August 31 the latest (preferrably earlier) >> > - September 2023: public review period (30 days) >> > - October 2023: another public review period, if needed; otherwise, get >> > comittee specification ready and voted upon >> > - October (maybe November, if we're running late) 2023: virtio 1.3 >> > released >> > >> > The most important dates are feature freeze on Jul 1 and change freeze on Aug >> > 1, I guess; for the rest, we depend on whether people are out on PTO, which >> > kind of feedback we get, etc. -- but as long as we release >> > 1.3 in 2023, I'll be happy enough. >> >> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :) >> >> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch. >> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html >> >> 2. first user of aq for legacy access at v7. >> 2 patches. First 2 are Fixes. >> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html >> >> Both need few more days of review and vote. >> Shall we please have few days in July for them so that it can be part of 1.3? >> or whole July is needed to prepare the draft spec? > > I think it's not too bad, projects that do releases every couple of > months can afford to be strict, we do them ones a year and a half > it makes sense to be flexible. Yes, my only concern is to avoid slipping too badly -- and the "feature freeze" period was actually intended to give us some time to wrap up outstanding features. For the inner header hash, I see there's already an issue (#173), so it's good. I have not followed the aq legacy access feature -- if everyone agrees that we should be able to vote on it in July, we should have an issue for it as well (I cannot find one just by looking at titles.) Any other features that people are aware of?

On Fri, Jun 30, 2023 at 10:47:33AM +0200, Cornelia Huck wrote:
> On Thu, Jun 29 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote:
> >> Hi Cornelia, Michael,
> >>
> >> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> >> > open.org> On Behalf Of Cornelia Huck
> >> > Sent: Wednesday, April 12, 2023 12:17 PM
> >>
> >> > >> - July 1st 2023: enter feature freeze; all proposed changes must at
> >> > >> least have an open github issue that refers to a proposal on-list
> >> > >> - August 1st 2023: enter change freeze; everything needs to have been
> >> > >> voted upon (i.e. we can start with preparations for a release like
> >> > >> compiling the change log)
> >> > >> - at the same time, fork virtio-next, which can be used for development
> >> > >> while we're working on the release
> >> > >> - August/September 2023: prepare draft, initiate initial voting etc.
> >> > >
> >> > > Hmm looks like you forgot a 30 day the public review period (or is
> >> > > that included in the "etc"? ). During this period we will likely
> >> > > receive review comments which we have to address. Should the changes
> >> > > turn out to be material, another public review period will be required.
> >> > > Let's spell it out please.
> >> >
> >> > Yeah, that's what I meant with "etc"... let's make this:
> >> >
> >> > - August 2023: prepare draft, aim to have it ready and voted upon by
> >> > August 31 the latest (preferrably earlier)
> >> > - September 2023: public review period (30 days)
> >> > - October 2023: another public review period, if needed; otherwise, get
> >> > comittee specification ready and voted upon
> >> > - October (maybe November, if we're running late) 2023: virtio 1.3
> >> > released
> >> >
> >> > The most important dates are feature freeze on Jul 1 and change freeze on Aug
> >> > 1, I guess; for the rest, we depend on whether people are out on PTO, which
> >> > kind of feedback we get, etc. -- but as long as we release
> >> > 1.3 in 2023, I'll be happy enough.
> >>
> >> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)
> >>
> >> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
> >> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html
> >>
> >> 2. first user of aq for legacy access at v7.
> >> 2 patches. First 2 are Fixes.
> >> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html
> >>
> >> Both need few more days of review and vote.
> >> Shall we please have few days in July for them so that it can be part of 1.3?
> >> or whole July is needed to prepare the draft spec?
> >
> > I think it's not too bad, projects that do releases every couple of
> > months can afford to be strict, we do them ones a year and a half
> > it makes sense to be flexible.
>
> Yes, my only concern is to avoid slipping too badly -- and the "feature
> freeze" period was actually intended to give us some time to wrap up
> outstanding features.
>
> For the inner header hash, I see there's already an issue (#173), so
> it's good. I have not followed the aq legacy access feature -- if
> everyone agrees that we should be able to vote on it in July, we should
> have an issue for it as well (I cannot find one just by looking at
> titles.)
>
> Any other features that people are aware of?


Was hoping for virtio-can but it looks like it's still in RFC stage.
I am guessing the spec should be copied to people who reviewed
the driver.

--
MST

On Fri, Jun 30, 2023 at 10:47:33AM +0200, Cornelia Huck wrote:
> On Thu, Jun 29 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote:
> >> Hi Cornelia, Michael,
> >>
> >> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> >> > open.org> On Behalf Of Cornelia Huck
> >> > Sent: Wednesday, April 12, 2023 12:17 PM
> >>
> >> > >> - July 1st 2023: enter feature freeze; all proposed changes must at
> >> > >> least have an open github issue that refers to a proposal on-list
> >> > >> - August 1st 2023: enter change freeze; everything needs to have been
> >> > >> voted upon (i.e. we can start with preparations for a release like
> >> > >> compiling the change log)
> >> > >> - at the same time, fork virtio-next, which can be used for development
> >> > >> while we're working on the release
> >> > >> - August/September 2023: prepare draft, initiate initial voting etc.
> >> > >
> >> > > Hmm looks like you forgot a 30 day the public review period (or is
> >> > > that included in the "etc"? ). During this period we will likely
> >> > > receive review comments which we have to address. Should the changes
> >> > > turn out to be material, another public review period will be required.
> >> > > Let's spell it out please.
> >> >
> >> > Yeah, that's what I meant with "etc"... let's make this:
> >> >
> >> > - August 2023: prepare draft, aim to have it ready and voted upon by
> >> > August 31 the latest (preferrably earlier)
> >> > - September 2023: public review period (30 days)
> >> > - October 2023: another public review period, if needed; otherwise, get
> >> > comittee specification ready and voted upon
> >> > - October (maybe November, if we're running late) 2023: virtio 1.3
> >> > released
> >> >
> >> > The most important dates are feature freeze on Jul 1 and change freeze on Aug
> >> > 1, I guess; for the rest, we depend on whether people are out on PTO, which
> >> > kind of feedback we get, etc. -- but as long as we release
> >> > 1.3 in 2023, I'll be happy enough.
> >>
> >> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :)
> >>
> >> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch.
> >> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html
> >>
> >> 2. first user of aq for legacy access at v7.
> >> 2 patches. First 2 are Fixes.
> >> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html
> >>
> >> Both need few more days of review and vote.
> >> Shall we please have few days in July for them so that it can be part of 1.3?
> >> or whole July is needed to prepare the draft spec?
> >
> > I think it's not too bad, projects that do releases every couple of
> > months can afford to be strict, we do them ones a year and a half
> > it makes sense to be flexible.
>
> Yes, my only concern is to avoid slipping too badly -- and the "feature
> freeze" period was actually intended to give us some time to wrap up
> outstanding features.
>
> For the inner header hash, I see there's already an issue (#173), so
> it's good. I have not followed the aq legacy access feature -- if
> everyone agrees that we should be able to vote on it in July, we should
> have an issue for it as well (I cannot find one just by looking at
> titles.)
>
> Any other features that people are aware of?


Was hoping for virtio-can but it looks like it's still in RFC stage.
I am guessing the spec should be copied to people who reviewed
the driver.

--
MST

On Fri, Jun 30, 2023 at 10:47:33AM +0200, Cornelia Huck wrote: > On Thu, Jun 29 2023, "Michael S. Tsirkin" <mst@redhat.com> wrote: > > > On Thu, Jun 29, 2023 at 05:41:34PM +0000, Parav Pandit wrote: > >> Hi Cornelia, Michael, > >> > >> > From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- > >> > open.org> On Behalf Of Cornelia Huck > >> > Sent: Wednesday, April 12, 2023 12:17 PM > >> > >> > >> - July 1st 2023: enter feature freeze; all proposed changes must at > >> > >> least have an open github issue that refers to a proposal on-list > >> > >> - August 1st 2023: enter change freeze; everything needs to have been > >> > >> voted upon (i.e. we can start with preparations for a release like > >> > >> compiling the change log) > >> > >> - at the same time, fork virtio-next, which can be used for development > >> > >> while we're working on the release > >> > >> - August/September 2023: prepare draft, initiate initial voting etc. > >> > > > >> > > Hmm looks like you forgot a 30 day the public review period (or is > >> > > that included in the "etc"? ). During this period we will likely > >> > > receive review comments which we have to address. Should the changes > >> > > turn out to be material, another public review period will be required. > >> > > Let's spell it out please. > >> > > >> > Yeah, that's what I meant with "etc"... let's make this: > >> > > >> > - August 2023: prepare draft, aim to have it ready and voted upon by > >> > August 31 the latest (preferrably earlier) > >> > - September 2023: public review period (30 days) > >> > - October 2023: another public review period, if needed; otherwise, get > >> > comittee specification ready and voted upon > >> > - October (maybe November, if we're running late) 2023: virtio 1.3 > >> > released > >> > > >> > The most important dates are feature freeze on Jul 1 and change freeze on Aug > >> > 1, I guess; for the rest, we depend on whether people are out on PTO, which > >> > kind of feedback we get, etc. -- but as long as we release > >> > 1.3 in 2023, I'll be happy enough. > >> > >> We have two extension features that has gone through several reviews and are in advance stage (and also late) for 1.3. :) > >> > >> 1. inner hash v19, rolling to v20 anytime this week. 1 Patch. > >> [1] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00490.html > >> > >> 2. first user of aq for legacy access at v7. > >> 2 patches. First 2 are Fixes. > >> [2] https://lists.oasis-open.org/archives/virtio-comment/202306/msg00491.html > >> > >> Both need few more days of review and vote. > >> Shall we please have few days in July for them so that it can be part of 1.3? > >> or whole July is needed to prepare the draft spec? > > > > I think it's not too bad, projects that do releases every couple of > > months can afford to be strict, we do them ones a year and a half > > it makes sense to be flexible. > > Yes, my only concern is to avoid slipping too badly -- and the "feature > freeze" period was actually intended to give us some time to wrap up > outstanding features. > > For the inner header hash, I see there's already an issue (#173), so > it's good. I have not followed the aq legacy access feature -- if > everyone agrees that we should be able to vote on it in July, we should > have an issue for it as well (I cannot find one just by looking at > titles.) > > Any other features that people are aware of? Was hoping for virtio-can but it looks like it's still in RFC stage. I am guessing the spec should be copied to people who reviewed the driver. -- MST

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Cornelia Huck
> Sent: Friday, June 30, 2023 4:48 AM

> For the inner header hash, I see there's already an issue (#173), so it's good. I
> have not followed the aq legacy access feature -- if everyone agrees that we
> should be able to vote on it in July, we should have an issue for it as well (I
> cannot find one just by looking at
> titles.)
>
For legacy registers access, it is https://github.com/oasis-tcs/virtio-spec/issues/167

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis-
> open.org> On Behalf Of Cornelia Huck
> Sent: Friday, June 30, 2023 4:48 AM

> For the inner header hash, I see there's already an issue (#173), so it's good. I
> have not followed the aq legacy access feature -- if everyone agrees that we
> should be able to vote on it in July, we should have an issue for it as well (I
> cannot find one just by looking at
> titles.)
>
For legacy registers access, it is https://github.com/oasis-tcs/virtio-spec/issues/167

> From: virtio-comment@lists.oasis-open.org <virtio-comment@lists.oasis- > open.org> On Behalf Of Cornelia Huck > Sent: Friday, June 30, 2023 4:48 AM > For the inner header hash, I see there's already an issue (#173), so it's good. I > have not followed the aq legacy access feature -- if everyone agrees that we > should be able to vote on it in July, we should have an issue for it as well (I > cannot find one just by looking at > titles.) > For legacy registers access, it is https://github.com/oasis-tcs/virtio-spec/issues/167