The lag there is not due to the review time. How many maintainers were involved? 300? Because I'm still finding it hard to understand how the work of 300 people handling 300 commits cannot be parallelized into months (per your own stat.)

▲

qustio 2 hours ago | parent [-]

To be clear my original statement was that the bottleneck was most likely not mechanical code changes (where CC would have the most direct speedup) but everything else involved in the process (testing, discussion/approval, inclination towards caution, deliberately narrowly scoped changes, etc).

Not that the Linux kernel approval procedures couldn't be streamlined, work couldn't be parallelized, or anything else like that, which would be a different discussion entirely.

You stated that Claude Code could have significantly sped up the process, so the burden of evidence here should be on how specifically these patches would have benefited/time saved from using LLMs. Hand wavingly saying "LLMs = faster" is too vague/broad of a claim without providing any evidence (and also unfalsifiable).

▲

qarl 2 hours ago | parent [-]

Right.

And what I'm saying is I refuse to believe the Linux kernel approval procedures are that inefficient. Therefore, your belief "bottleneck was most likely not mechanical code changes" is most likely incorrect.

It would be interesting to get the actual answer to this question.

EDIT: Substantially changing your argument after posting isn't nice. But to answer your charge - no - I never made that claim.

▲

qustio an hour ago | parent [-]

Sorry, I didn't feel like this thread needed to be dragged out any longer since it's going in circles at this point and expanded my comment, but I didn't realize you had already replied.

	▲	qarl 23 minutes ago \| parent [-]
		Well - not really a circle. I keep saying the same thing over and over and you keep throwing arguments at it, unsuccessfully.