SLO for patch review at one-quater-year?

SLO for patch review at one-quater-year?

[Carlos O'Donell]

Community,

I have been tracking the patch review latency for the project using
patchwork. I've been trying to use that metric to adjust my own
patch review behaviour to ensure that patches get reviewed.

My goal here is to improve the patch review experience for all
developers, which I expect to lead to a positive virtuous cycle
for the project.

I managed at one point in the last 4 months to get the mean patch
review latency down to ~130 days. This still seems too high to me.

I would like to arbitrarily set my own SLO (service level objective)
at one-quarter-year, that is to have patches take no longer than a
quarter to get through review for anyone posting to the list.

The SLI (service level indicator) today is at ~164 days. With an
SLO of 91 days it means I am in error of 73 days. This is a huge
error which is quite hard to fix.

The simplest hack is to start with the oldest patches on the list
and do a mix of reviewing old patches and new patches to move the
error bar in the right direction.

I encourage everyone to look at patchwork for old patches we could
review or cleanup (State NEW, delegate NOBODY):
https://patchwork.sourceware.org/project/glibc/list/?series=&submitter=&state=1&q=&archive=&delegate=Nobody

I compute the mean patch age with State NEW only (non-archived):
https://patchwork.sourceware.org/project/glibc/list/?series=&submitter=&state=1&q=&archive=&delegate=

It has always been the goal of the Monday-morning patch review to
improve the patch review process, and I believe it has, but it
for *me* an SLO means something I can measure and act against.

Thoughts?

-- 
Cheers,
Carlos.