[ovs-dev] ideas for improving the OVS review process

[Ben Pfaff]

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.