OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [virtio] [PATCH] virtio-net subcommittee proposal


Hi Stefan,

> From: Stefan Hajnoczi <stefanha@redhat.com>
> Sent: Wednesday, April 5, 2023 9:11 AM
> 
> On Mon, Apr 03, 2023 at 03:06:02PM +0000, Parav Pandit wrote:
> >
> >
> > > From: Stefan Hajnoczi <stefanha@redhat.com>
> > > Sent: Monday, April 3, 2023 10:58 AM
> > >
> > > Why not just do this in the VIRTIO TC?
> > >
> > > The workflow and infrastructure for developing the VIRTIO spec already
> exists.
> > > A weekly or bi-weekly virtio-net call can be scheduled.
> > >
> >
> > > Are you hitting scalability bottlenecks or limitations with the current VIRTIO
> TC?
> >
> > May be.
> > SC is mainly networking specific interested members who has the described
> mission and SOP.
> > This requires interworking on many features, discussion, and design in phased
> approach like suggested above.
> >
> > Also it is too much of the ask for the whole TC to get involved in such process.
> 
> Today, voting members get involved in parts of VIRTIO to the extent that they
> want. They can ignore certain parts and abstain from voting.
> 
This stays as is.
The work produced by the SC in form of spec is up for voting members of the main TC to review and/or ignore.

> If we get to a point where the majority of voting members abstains regularly,
> then I think it's worth discussing how to scale the TC to avoid wasting people's
> time with votes that they abstain from. 
We haven't seen this either.
> I haven't seen this happen and I think
> people who are voting members try to take a broad view as custodians of the
> spec rather than focussing on just one feature they care about.
> 
> > Better to start with forum that is focused on mission and SOP, committed to
> deliver on agreed timeline in 4 step approach.
> >
> > Few months later when operation works fine, may be main TC can also adopt
> similar approach to wider level.
> 
> Discussing this is important for the wider VIRTIO community. If the process
> needs changes for virtio-net, then other parts of VIRTIO can probably also
> benefit.
> 
May be.

> Can you explain why the regular VIRTIO process is not suitable for developing
> virtio-net? Can you give examples of issues you hit in the past?

A SC proposes to follow 4 step approach of requirements review, design review, spec writing and review, submitting to main tc for review + vote.
(Instead of intermixing all of these).

For example,
A net SC committee or main TC may not be able to follow above 4 step process for virtio-foo device in timely manner.
Some SC member(s) may have interest in main TC spec wide work and net SC both, they will participate at both level.

AT the end, Virtio net SC is just a SC of networking experts that work well together, review, comment, submit towards a mission and SOP in timely manner using the OASIS open forum.
Then they submit the work to the main committee, ask them to review and vote.
It a platform that enables better collaboration.

Once a model is operationally working, it makes sense to adopt to 19 or 20 different device types. :)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]