On Wed, 30 Apr 2008, Andrew Morton wrote:The problem I see with both -mm and linux-next is that they tend to be better at finding the "physical conflict" kind of issues (ie the merge itself fails) than the "code looks ok but doesn't actually work" kind of issue. Why? The tester base is simply too small. Now, if *that* could be improved, that would be wonderful, but I'm not seeing it as very likely. I think we have fairly good penetration these days with the regular -git tree, but I think that one is quite frankly a *lot* less scary than -mm or -next are, and there it has been an absolutely huge boon to get the kernel into the Fedora test-builds etc (and I _think_ Ubuntu and SuSE also started something like that). So I'm very pessimistic about getting a lot of test coverage before -rc1. Maybe too pessimistic, who knows? Linus --
| Mark Lord | 2.6.25-rc8: FTP transfer errors |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Steven Whitehouse | [GFS2 & DLM] Proposed patches for 2.6.20 merge window [0/54] |
| Tony Lindgren | [PATCH 54/90] ARM: OMAP: Update timer32k.c to compile |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Alexey Dobriyan | Re: [GIT]: Networking |
| Andrew Morton | Re: [BUG] New Kernel Bugs |
git: | |
