patch quality [LWN.net]

patch quality

Posted May 4, 2006 18:57 UTC (Thu) by hingo (guest, #14792)
Parent article: Briefly: patch quality, CKRM, likely(), and vmsplice()

As usual, Andrew probably is right on the money. Maybe one problem is, that earlier Andrew, and long ago Linus, knew the kernel community personally, such that they'd know who's patches to trust and who's to be sceptical about or even reject. Maybe the sheer size and speed of the kernel community has outgrown that mode of development?

What comes to mind would be an automated reputation system for patches, that could give Andrew hints in what patches are likely to be mature. Think google pagerank for git! Something like this: If patches from a certain developer often end up rejected, be sceptical about that developer. If patches from some developer often end up being patched with small fixes, be sceptical about that. If a developer has contributed tons of code which has been in the linus-kernel for a long time with relatively few fixes, the developer is worthy of trust. There is probably also lots of data mining to be had from the different trees out there, from which Andrew and eventually Linus are feeding.

(Log in to post comments)

patch quality

Posted May 5, 2006 6:13 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

this has basicly been implemented already.

linus and andrew accept pretty much unconditionally from people who have consistantly provided good work in the past, others need to funnel their work through the trusted 'lieutenants' who are supposed to be doing the checking.

however everyone gets lazy at times and this generates posts like andrew's every once in a while.

patch quality

Posted May 5, 2006 13:42 UTC (Fri) by jzbiciak (✭ supporter ✭, #5246) [Link]

Andrew is sufficiently respected that he probably should just bounce back patches with a "Bzzzt... get it right, I'm not debugging this" for problematic patches. Of course, the fact that he wasted time trying to compile it to begin with still slows him down.