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. * 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. I hope that there can be some discussion here. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
