[STATS] Auto-update patchwork for committed patches

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

Hello,

We have been using patchwork for status tracking for a couple of years 
now (it's been a great run since the previous one didn't last too long) 
and we're at a point where we use it enough to want to maintain its 
state more closely.

To make sure that the backlog remains sane enough to be useful, I've 
been running a cron job that reviews new commits to the master branch 
daily and closes matching patchwork patches as COMMITTED.  This works 
only when the diff of a commit is exactly the same as that in patchwork; 
the script ignores commits that don't have a matching diff in patchwork.

I get an email every day from the job, telling me which commits had 
matching patches on patchwork and which didn't.  Going forward, I'm 
going to publish approximately weekly (until I can get another cron job 
that parses these emails and does this automatically) statistics of how 
many (and which) commits did not have a matching patch on patchwork.

The intent is to try and drive behaviour towards pushing patches exactly 
as they were posted upstream.  It's understandable that there may be 
some trivial nits that get fixed before pushing, but the ideal behaviour 
there should be to post a [committed] patch to the list so that there's 
always a matching patch on list (and on patchwork) for every commit. 
This has a number of advantages:

1. Verifiable claim that every commit in the repository has a record on 
the mailing list (including conversations following the patch) and 
patchwork, thus improving auditability and transparency.
2. A pre-commit CI run, through patchwork for every such commit
3. It enables further automation, such as marking previous versions of 
patches with the same subject line as superseded (which makes subject 
lines important or maybe the use of something like b4, but that's a 
different topic for later)

If you find a commit that that's incorrectly marked as MISSING, please 
let me know and we can dig out the root cause for it.

Thanks,
Sid

The stats for the last week-ish
===============================

In the last 10 days, there have been 34 commits to glibc and 22 had 
matching patches on patchwork.  This makes it a success rate of 64.7%. 
Here are the commits that were missing from patchwork:

4571fb8fe64644c79d91a8f76c148a05b7088ea8 Update hurd/intr-msg.c to be 
more portable: MISSING
3f433cb895dee51dee57cb487bc33b1425fa7ef6 Update 
sysdeps/mach/hurd/ioctl.c to make it more portable: MISSING
a26238d3ca21fda6d7d41b4d56541fcf4546fbe7 Enable new device_open_new RPC 
in libmachuser.: MISSING
bf88b47ecb54888a789c02fa81aa4ab81ec2f3a5 Revert "riscv: Resolve symbols 
directly for symbols with STO_RISCV_VARIANT_CC.": MISSING
ab5aa2ee3d3f978e474803cbbc5fe805ad30e293 dlopen: skip debugger 
notification for DSO loaded from sprof (bug 30258): MISSING
d6c72f976c61d3c1465699f2bcad77e62bafe61d hurd: rule out some mach 
headers when generating errno.h: MISSING
3ca9f43d1007956251130ee5a59abb63bff8a6b6 Stop checking if MiG supports 
retcode.: MISSING
088136aa02de6fa13061ef6f754071a5652fdabd i386: Use pthread_barrier for 
synchronization on tst-bz21269: MISSING
114f1b7881e63e2b4e5d0e9a9e4fb142b9cd886c hurd: Fix computing user stack 
pointer: MISSING
e333759f7752593a69a8f9920a247ed3878fafef hurd: Fix sc_i386_thread_state 
layout: MISSING
ce96593c882b393461084048533120e9c1e9d328 hurd: Align signal stack 
pointer after allocating stackframe: MISSING
ff0f87632a74a369a2b992f4436ae406065a4012 hurd: Fix aligning signal stack 
pointer: MISSING