On Tue, Jul 20, 2021, at 20:41, Ben Pfaff wrote: > The OVS review process has greatly slowed over the last few years. This > is partly because I haven't been able to spend as much time on review, > since I was once the most productive reviewer. Ilya has been able to > step up the amount of review he does, but that still isn't enough to > keep up with the workload. > > We need to come up with some way to improve things. Here are a few > ideas, mostly from a call earlier today (that was mainly about the OVS > conference). I hope they will prompt a discussion. > > * Since patches are coming in, we have people who are knowledgable about > the code. Those people should be pitching in with reviews as well. > It doesn't seem like they or their managers have the right incentives > to do that. Maybe there is some way to improve the incentives. > > * The Linux kernel uses something like a "default accept" policy for > patches that superficially look good and compile and boot, if there is > no review from a specific maintainer within a few days. The patches > do get some small amount of review from a subsystem maintainer. OVS > could adopt a similar policy. >
Hi Ben, This policy was successful for DPDK as well. It creates an incentive to contribute negative feedback in time. Getting change requests after weeks or months means that the original author has to come back to the series after having switched subject, which slows down patch development, or even halts it. With the caveat that of course all integrated patches still need approval from a subsystem maintainer, I think it would be useful. Additional maintainers would be required to make it work. If needed we would be happy to help on our area of expertise, conntrack and HW offloads. > * Some lack of review can be attributed to a reluctance to accept a > review from a reviewer who is at the same company as the patch > submitter. There is good reason for this, but it is certainly > possible to get quality reviews from a coworker, and perhaps we should > relax the convention. > > * A flip side of the above could be to codify the requirement for review > from a non-coworker. This would have the benefit of being able to > push back against requests to commit unreviewed long series on the > basis that it hasn't been reviewed by a third party. > At Nvidia we will change our policy of doing each others review prior to public submission, and to do those instead on the mailing list. Having only a 'Reviewed-by' line appended after an internal process does not show that the review was properly done. If the review is public, it can be judged on its technical merit. > I hope that there can be some discussion here. > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > -- Gaetan Rivet _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
