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

[Stefan Hajnoczi <stefanha@redhat.com>]

On Sat, Apr 08, 2023 at 02:28:22PM +0000, Parav Pandit wrote:
> 
> > From: Stefan Hajnoczi <stefanha@redhat.com>
> > Sent: Friday, April 7, 2023 12:19 PM
> 
> >   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?
> >
> Patches to send on existing OASIS public forum mailing lists.
> It can be either
> a. single mailing list of virtio-net + CC to virtio-dev+virtio-comment.
> So that all virtio TC members, academic and hobbyists can comment and contribute.
> or
> b. existing virtio-dev and virtio-comment mailing list.
> Don't have any strong preference for it.
> 
> Since all spec WIP patches also done in the OASIS mailing lists, non-members should be able to provide feedback too.
> (Like today).
> 
> > >
> > > " 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.
> > 
> No.
> Like we described in the first email, in step 8.d.
> Virtio TC reviews AND (followed by) vote.
> 
> > 
> > What happens when someone on the virtio mailing list requests non-editorial
> > changes to a spec change originating from the subcommittee?
> > 
> Not sure I understood the question.
> Let me try,
> When subcommittee worked on a spec change, they will send patch for review to virtio TC.
> This is step 8.d in my first email.
> 
> As usual, it is reviewed today.
> If there is design change suggested by virtio-tc, SC goes back and re-evaluate.
> If needed, it will redesign.
> 
> Those who has interest in such reviews, should definitely be part of the Net SC to have Net SC productive.
> 
> If no comments from virtio tc, a week later or so, author ask for 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.
> > 
> Sure. This isn't a problem.
> It is very likely that they are not in a shape yet for wider audience to review as its WIP.
> TC members can always comment early on them.
> 
> The point is SC members must pass them as they do the work jointly.

The VIRTIO process addresses spec review and I think it's most efficient
to use the virtio mailing list to iterate on spec patches. Drafting the
spec elsewhere before sending it to the virtio mailing list extends the
amount of time that review takes (especially when there is feedback that
requires changes).

If you want confirmation that people agree with a patch, they can send
"Reviewed-by" replies.

Patch emails can be labeled with "RFC" (Request for Comments) when the
patch is incomplete and requires input from others. There is no need to
be concerned about patches that are not in shape for voting yet. As long
as they are labeled RFC, people can skip them.

What the VIRTIO process doesn't address is requirements and design. I
prefer a lightweight solution: a recurring call to discuss these things,
email discussion (when necessary), and then someone takes on the
responsibility to write spec patches and submits them to the mailing
list where the whole VIRTIO community reviews them. I think voting is
unnecessary (and adds complexity/rules) and it will get tiring to take
everything through requirements and design stages, so the process should
be informal and allow combining/skipping steps as appropriate.

But, I feel close enough to understanding your proposal that pressing
these points about making it more lightweight is less important. One
final thing I want to mention is that calling it "working group" or
something similar would help avoid confusion with OASIS subcommittees.

Thanks,
Stefan

Attachment: signature.asc
Description: PGP signature