I would love to find better metrics than changesets and lines of codes — I agree that both are awful ways of measuring actual software-development work. I have yet to find something better, though; suggestions welcome.
WireGuard for example is only a relatively small changeset, but has an huge impact for many uses, you can find many comments, posts, write ups, about it all over the internet. Many knew that this feature was going to be huge, well before merge into linux.
On the other hand, if almost no one is discussing a particular change (e.g. the removal of 20k lines of driver code), then the impact will either be very low and unimportant or it will unexpectedly become important, but there was no way you could have known it beforehand.
sorry you spent too much time on "learning", we need more "corbet-curve-units" from you.
In this case I think a lot of people are wondering what they changed. Would it be possible to extract that info from the paths modified, filtered with some handwritten rules to classify the changes? For example, did they commit driver code for their own hardware, or did they touch other areas of the kernel? How much of each?