Posted May 4, 2006 18:57 UTC (Thu) by hingo
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.
to post comments)