Vetter: Linux Kernel Maintainer Statistics

Maybe some of the ways I looked into measuring "how many maintainers do we have" that don't really work:

- Counting entries in MAINTAINERS. We have plenty people even in the gpu subsystem that submit their one driver, getting their maintainer entry added and then disappear. So just counting maintainer entries doesn't tell you who's actually active (and how much they're doing).

- Counting commits of people listed in MAINTAINERS. We have a big chunk of folks who are maintainer for something, but mostly write fixup patches all over the tree (or heavily contribute in other areas). I think given how hierarchical and big the kernel community is, counting all commits someone does even in areas they're not maintainers doesn't tell us much. It also makes things really complicated if you want to look at a specific subsystem or git tree.

The inverse also happens: Lots of people assume maintainer duties (of last resort, or just temporary, or whatever) for areas they're not listed in MAINTAINERS.

- Counting reviews (whether listed in MAINTAINERS or not). Reviewed-by tags in general are on an uptick (a slow one, but it's fairly steady). So you'd need to do some pretty serious statistic to try to compute out the overall trend to see how many maintainers there are, and I don't think any kind of useful signal will come out of that exercise.

- Looking at replies on the mailing lists. That would be a full-time research project, starting with simply getting reliable archieves of all the mailing lists used by the kernel community. And then trying to match patches against their discussions (usually the diffs don't match, and often the patch id doesn't either due to fixups when applying).

Given all that I figured looking at self-commits is the best metric I can have: I can crunch the numbers on the side without this becoming a full time research project. And it since it looks at what actually happens instead of what's documented in MAINTAINERS it has a higher chance of reflecting reality.