Re: [virtio] [PATCH] virtio-net subcommittee proposal

[Stefan Hajnoczi <stefanha@redhat.com>]

On Wed, Apr 05, 2023 at 05:36:37PM +0000, Parav Pandit wrote:
> 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. :)

I feel like you're proposing a solution without explaining the problem
that it solves.

I don't know why a 4-step process or a sub-committee is necessary.

Why not just schedule a recurring call for face-to-face communication,
have written discussions on the mailing list, and send spec patches?

An answer to that will help me understand why the 4-step process and
sub-committee are needed.

Thanks,
Stefan

Attachment: signature.asc
Description: PGP signature