RE: [virtio-comment] RE: [PATCH v10 06/10] mmio: document ADMIN_VQ as reserved

[Parav Pandit <parav@nvidia.com>]

> From: Cornelia Huck <cohuck@redhat.com>
> Sent: Wednesday, March 8, 2023 11:24 AM

> >> And I wonder whether it's worth it - it definitely makes contributing
> >> to Linux harder, and even within Linux it pushes contributors away.
> > The number of virtio spec contributors are in order of magnitude less than
> Linux kernel or just the Linux netdev.
> > Patch split up reduces lot of time author and reviewers.
> > For example, interrupt moderation at v10 can be very easily split up where
> prep patch can have RB tag and v11 doesn't need reviewers and author's time.
> > Your work here with 10 patches is yet another good example of it.
> > I remember Max and I started with 6 patches... and current 10 are more
> useful way to split them.
> 
> I'd argue that splitting changes in a way that makes it easy for reviewers is a
> good thing for any project (although practices on many forges seem to go into
> another direction...)
> 
In my experience in dpdk, Linux netdev, rdma, nvme, tells me that patch splitting is common practice.

> >
> >> At least for Linux
> >> tracking history in a precise way is extremely important since it's
> >> helpful with stability. Spec is very different.
> >>
> >> Until we have a good contribution documentation I think we should not
> >> ask people to follow a pseudo Linux work flow with requests like
> >> "please split this patchset up" or "track changes across patch versions"
> >> simply because there's no good docs to teach people what exactly is
> >> the best practice.
> >
> > Yes, I wanted to update the contributing document. It is in my to-do list.
> > But given the small crowd of contributors right now, almost everyone is
> familiar with the RB, ack tag.
> > At moment it has two main reasons.
> >
> > 1. Acknowledge the work and efforts that go in the review
> 
> I agree, and I try to include tags when applying.
> 
Sure. It is not about you.
It is about the patch author when he/she sends v9 to v10, adding R-b tag in v10 (for the already reviewed work of v9) helps to ack and speed up the v10 review.

> > 2. When in question, reach out later to the spec author or reviewers to know
> about context/design etc.
> > 3. Same reviewer doesn't need to go through the patch which already has RB
> tag of him/her.
> 
> I tend to use R-b in that way as well, but it relies on the patch author not doing
> substantial changes between versions...
> 
> I guess the usage of R-b et al in the virtio spec stems from the fact that many
> contributors are also Linux and/or QEMU contributors  -- not sure if it makes
> sense to enshrine their usage, but
> 
> 4. We can get an R-b from a non-TC member who is an expert on the topic (and
> follows standard Linux/QEMU/... practices.)
> 
The intent here was between vN to v(N+1).
Virtio spec maintainers are likely adding R-b when they merge anyway. No issue there.

> In the end, how the TC members are voting is the only thing that matters for
> inclusion.