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

[Stefan Hajnoczi <stefanha@redhat.com>]

On Thu, Apr 06, 2023 at 06:03:23PM +0000, Parav Pandit wrote:
> 
> > From: Stefan Hajnoczi <stefanha@redhat.com>
> > Sent: Thursday, April 6, 2023 11:52 AM
> 
> > This was not mentioned in your original email. 
> SOP is written as wider purpose and not nit picking specific operational/verbose detail.
> 
> > Taking virtio-net away into your
> > own subcommittee and relegating the VIRTIO TC to making editorial changes is
> > a major change. 
> 
> All I can say is, you have a major misunderstanding and/or paranoia.
> 
> I disagree to almost all the words written above.
> Above text is completely wrong attribution of what we described in previous email and first emails.
> 
> First, it is not "mine" or "yours".
> As repeatedly told, net SC is made from virtio TC members. So, it is not "mine".
> It is proposed by 4 virtio tc member organizations which are active spec contributors, reviewers, spec implementors, spec consumers , not "me".

I apologise for characterizing it as "your" subcommittee. It was
inaccurate and I won't use that term anymore.

> Secondly, in the first proposal email it is clearly mentioned that main tc must review the work produced by net sc.
> And same is also repeated in previous email response.
> 
> If you assumed, vN at stage 3, and vN+1 is at stage 4 for editorial changes by main TC, then it is wrong assumption.

Here is what you wrote:

  In one line, we anticipate that actual spec patch vN to vN+1 should be around editorial changes and not design changes.

I interpreted this to mean finalizing the spec change before sending it
to the mailing list. That would exclude those who are not members of the
sub-comittee from providing meaningful feedback and that was the cause
for my concern.

Can you illustrate what you are proposing by giving an example of where
v1, v2, etc are sent and who reviews them?

> 
> 3rd, main proposal clearly mentions the function of SC as first point, snippet:
> 
> " Consults virtio tc, feed and use master virtio specification for
>    the standard functionality across devices when applicable"
> 
> So yet again, net SC do not want to bypass main virtio TC.

This does not clarify the role that the VIRTIO TC plays in the process.
Is it for editoral changes only? That is the part that I find
concerning.

> 
> The whole perception of yours that Net SC is detached or "away" from main virtio TC is simply incorrect.
>
> > You need to make an effort to show why this process change is
> > good for the VIRTIO community, not just for you.
> >
> VIRTIO TC != VIRTIO community as per the OASIS virtio TC charter.
> 
> Secondly it is not for "me". It is proposed by list of companies from diverse area.
> Please refer to the original first email at the end.
>
> > VIRTIO operates like an open source project. Anyone can propose spec changes
> > or provide feedback. Whether that person is a hardware developer, hypervisor
> > developer, driver developer, academic, hobbyist, etc doesn't matter. You need
> > to accept that there are other stakeholders and engage in technical discussion
> > with them, not try to change the process so you can bypass them.
> > 
> Yet again wrong attribution of "bypassing" them.
> 
> Net SC DO NOT want to bypass anyone.
> If a hobbyist does not want to join virtio TC and still wants to contribute to virtio spec for net, what prevents such contribution? Nothing.
> Virtio main TC will review it as done today.

What happens when someone on the virtio mailing list requests
non-editorial changes to a spec change originating from the
subcommittee?

> 
> Also first draft clearly said, everyone is welcome to be part of the SC who share the same mission and SOP as SOP is asked by the OASIS.
> 
> Secondly,
> Net SC is platform for the virtio TC members to do organized work among the virtio TC members.
> Yet in the OASIS open forum.
> 
> Want to repeat that,
> 
> " 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."
> 
> Maybe you missed all above points.
> So let me repeat in different words.
> 
> 1. Net SC does the pre-work before generating the spec patches in OPEN forum of OASIS.
> 2. Weekly/bi-weekly as you suggest will have sync and discussion meetings to converge
> 3. Written documents produced by Net SC is visible via OPEN forum of OASIS.
> 4. Net SC reviews the spec patches before asking main TC to review.

Does "asking main TC to review" mean sending patches to the mailing list
where anyone can review them? I want to make sure I'm not confusing the
mailing list review and the TC vote.

Sending the patches straight to the virtio mailing list for review by
anyone reduces the turn-around time if changes are requested by someone
not on the subcommittee. I don't think reviewing spec patches within the
subcommittee first is advantageous.

> 5. Can main tc review the work of net sc while WIP? Sure, why not?
> 6. Can hobbyist see the work and comment occurred on the OASIS mailing list by net SC? Sure, why not?
> 7. SC consults the main TC when there is spec wide effect while writing the spec.
> 8. Net SC members are subset of VIRTIO TC members, as asked by OASIS, not defined by "me".
> 
> So, if you please stop attributing negative words "bypass", " relegating ", "yours", we will have constructive way forward.
> 
> > Here is a suggestion for achieving some of what you want within the existing
> > process:
> > 
> > - Send an email announcing a recurring public call to work on virtio-net
> >   enhancements suitable for PCI hardware implementation.
> It is not limited to only PCI hardware.
> > - For each call, send an agenda ahead of time listing specific
> >   virtio-net features that will be discussed.
> > - Conduct written discussions of requirements and design on the virtio
> >   mailing list as necessary.
> > - Agree on how to divide up the spec writing work.
> > - Spec writers submit the spec changes to the mailing list for review.
> >
> Exactly. 
> Stefan, what you wrote above is no different than what is proposed.
> This targeted efforts under OASIS purview is tagged as net-subcommittee.
> 
> So I am puzzled that you agree to do above way, but against tagging it as subcommittee even though its under purview of OASIS and under virtio TC.

To me the idea of a subcommittee is that the TC delegates voting to the
subcommittee. I'm trying to understand whether your proposal involves
that or not.

> 
> > This approach will allow you to get people on the same page before the spec
> > writing and review.
> > 
> > Here is how this approach matches what you've written:
> > 
> > > 0. Amount of changes a virtio net needs to undergo are huge that requires
> > better design approach than just "sending patches".
> > 
> > Requirements and design can be discussed in calls and/or on the mailing list
> > before sending patches.
> >
> Doing calls at virtio TC level requires change in the standing rule.
> "The Virtio TC has adopted a standing rule to conduct business only by electronic ballot, without Meetings"

This does not apply because collaborating on requirements and design is
not TC business.

The spec review that happens on the mailing list today is also not TC
business.

When spec changes are brought to a vote then it becomes TC business. The
vote is conducted by electronic ballot.

> > > 1. It is inefficient to discuss feature requirements in patch v11. Better
> > discussed, agree/disagree/revise in v1.
> > 
> > Ditto.
> > 
> > > 2. It is inefficient to introduce a feature in 2022 that cannot work
> > > with a Linux kernel algorithm written in year 2018
> > 
> > I guess you're referring to a specific incident? I don't know what you mean
> > though.
> >
> Not interesting to me to point fingers.
> Interest is in doing more technical work.
> So I will focus on it.
>  
> > > 3. It is efficient to discuss the design, theory of operation, pros and cons
> > before writing the normative spec.
> > > (even in plain text over mailing list).
> > 
> > Handled by call and/or mailing list.
> >
> > > 4. #3 is more important when virtio devices are being implemented as
> > > PCI hw devices to utilize the hw and also to gradually build new hw
> > 
> > Ditto.
> > 
> > > 5. Some of the virtio net features are inter-related and just posting a patch
> > per feature doesn't result in hw efficient spec.
> > 
> > Ditto.
> > 
> > > 6. Past authors have been in circles unable to modernize virtio spec (to a level
> > where other industry leading devices reached 2 to 3 years back).
> > > Circling in discussions and intermixing things.
> > 
> > Not solved by my approach and, importantly, also not solved by your approach.
> > VIRTIO is an open standard and anyone can participate, including people with
> > different perspectives.
> >
> Net SC do not take away any of it.
> What you propose and what we propose is same.
> We just tag a dedicate efforts as subcommittee under the purview of OASIS and virtio TC.

Then what is the relevance of points 6 and 7 to this discussion? I feel
like I'm missing something.

> >
> > Please let me know if you disagree with these points and I'll try to understand
> > what is missing from the approach I've suggested.
> 
> In summary, I disagree to the attribution you did about Net SC due to misunderstanding/paranoia (my humble guess).
> 
> And I totally agree to all the suggestions you made to do organized work, which is what tagged as Net SC.
> 
> Are you ok to tag your suggestions for organized work as "Net SC"?
>

Attachment: signature.asc
Description: PGP signature