Vetter: Linux Kernel Maintainer Statistics

DRM is definitely such a subsystem, with a bunch of the smaller driver trees being mostly not reviewed self-commits. Beyond an overall "does it compile" assessment there's not really any detailed (and definitely no per-patch) review going on.

> Another possibility is that what you see as a single monolithic subsystem is actually a collection of small subsystems, with a single shepherd between them and Linus. They could still benefit from group maintainership and a more explicit ack/review process, but the picture would be very different from that of a core subsystem that throws code into linux.git without any review. I would guess that the net statistics would be very different between net/ and drivers/net/, for example.

Yeah, splitting up net int drivers and core networking would be interesting. The trouble is that comparatively few things are maintained in sub-trees in the networking world (more than 50% goes in through Dave's tree directly). So you'd need to do a combination of git tree and path based analysis to figure out what's going on. That get's rather hairy.

I also didn't want to dig into other people's subsystems, just kernel overall and graphics.

> I would like to understand why you have such a negative opinion of "the guy who actually commits patches to the tree". To me, that's just one of the things that one can do to help running the community. Yes, sometimes the wrong person is assigned that task, but is it correct to turn that into a case against the task itself?

The linux kernel having relatively few committers compared to other open source projects isn't what I'm critizing here. I think it's not the most efficient way to run things (imo graphics would be real pain if we'd have half as many committers/maintainers as we do), but alas.

What irks me with self-commits that don't have a record of oversight by a 2nd person is that it creates a double-standard: Maintainers can get away with avoiding review, normal contributors (and they make 80-90% of contributions in a normal kernel subsystem, kvm being one of the exceptions here) simply cannot avoid that loop to jump through, even after having been around for years. In my opinion, the same rules should apply for everyone.

> > But there should be a supply of more junior maintainers (who will focus more still on their own work, instead of more on helping others), and so in aggregate I expect the number of self-commits to stay (relative to overall commits) the same. But it's going down.

> Why would those people _have_ to be maintainers? Even though I like group maintainership, one also has to recognize that more maintainers bring more overhead. I find it just as likely that newcomers end up focusing on a particular file or feature and gradually become the expert on that (and the maintainers actively seeks their opinion!), or that a company donates testing infrastructure. This distributes the maintainers' job and creates a community around the task of reviewing patches.

> And if you do have more maintainers, sending pull requests to each other, then you might end up in the situation of bullet 1 where the act of reviewing happens but isn't recorded except through a merge commit...

This is all valid, and it does explain how the kernel community manages to merge all that stuff with rather few people actually committing things. I think it's not the best way to organize a subsystem - group maintainership, even with fairly big group works much better than lots of trees with pull requests, or lots of reviewers with just a few patch monkeys doing all the applying.

What I'm worried about is that it's going down, while the kernel is growing. And as shown with the gpu subsystem, it's possible to keep up with the growth of an area and keeping the maintainer ratio (whatever you think is the optimum, or just how that subsystem traditionally has run the show) steady.

I'm also clear that counting self-commits is a pretty lousy metric to measure "how many maintainers do we have". But it's one you can measure and see historical trends. Perhaps looking at s-o-b chains would be interesting too, but at least in the gpu subsystems those generally happen for internal trees (for new hw that's not yet publicly announced), or from vendor trees. Both not really indicative of upstream maintainers. The big exception is mmotm, but I'm handling that already.

I also don't know why this is happening (I'm playing around with new ways to look at this, thus far nothing). But through the best available metric I could figure out it looks like maintainers overall are not keeping up with the growth. Aside: I didn't expect this when compiling the data at all. I knew it was fairly low, but assumed it'd be more or less steady. Everything else in the data was more or less matching my expectations.