On Wed, Apr 05, 2023 at 05:36:37PM +0000, Parav Pandit wrote:
> Hi Stefan, > >
>
From: Stefan Hajnoczi <> >
> Sent: Wednesday, April 5, 2023 9:11 AM > > >
> On Mon, Apr 03, 2023 at 03:06:02PM +0000, Parav Pandit wrote: > > > > > > > > >
>
From: Stefan Hajnoczi <> > > >
> 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
