On Mon, Oct 08, 2007 at 01:33:38PM -0700, H. Peter Anvin wrote:I would tend to agree. Right now I think the problem is that we are getting too little reviews, not enough. And someone who reviews patches, even if unknown, could be building up expertise that eventually would make them a valued developer, even while they are doing us a service. The concern that I suspect some people have is what if this gets abused by people who don't really bother to do a full review of a patch before they ack it. We could ask reviewers to include a URL to an LKML archive of their review, to make it easier to find a review of a patch so later on people can judge how effective they their review was. Unfortunately, this would be an added burden for the regular reviewers, so I doubt this would be well accepted as a practice. My suggestion is to not worry about this for now, and see how well it works out in practice. If we start getting half a dozen or more Reviewed-by: where the patch is pretty clearly not getting adequately reviewed, or where someone is obviously abusing the system, and social pressures aren't working, we can try to figure out then how we want to address that problem then. Let's not make the process too complicated unless we know it's necessary. Premature complexity is almost as bad as premature optimization.... - Ted -
| Arjan van de Ven | Re: Linux 2.6.26-rc4 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Ilpo Järvinen | Re: [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Evgeniy Polyakov | Re: [BUG] New Kernel Bugs |
