As I speculated, the reason the PPC64 Patchwork example was so out of date was that the PPC64 list had been folded into the vanilla PPC list, however the big problem right now is that Patchwork is "extra work" for maintainers, so right now they don't want to use it.
It ought to go without saying that a patch management system should make things *easier* for maintainers rather than harder(*). Ideally it should be easier to take a step using the patch management system that it is to take the same step without it. If there are places where taking the same step is harder or more time consuming in the patch management system, it should at least provide a clear down-the-track benefit to the maintainer to make it worth it to the maintainer to take that extra time.
The Patchwork maintainer is interested in improving it - particularly in ways that will make maintainers want to use it - so given that there is at least the beginnings of a project out there aimed at meeting the general requirements it makes some sense to put some effort into it.
Step 1 has to be to get a few members of that particular target group to document the procedures they go through to get a patch from the mailing list through to git and/or to some other state.
Jeremy - do you have any documentation for this from the last time you looked at implementing patch managemen, and if so is it up to date for Git?
(*) it should also make things easier for contributors, but maintainers are the critical pressure-point.