* Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > linux-next should not be second-guessing maintainers and should > > not act as an "approval forum" for controversial features, > > increasing the (already quite substantial) pressure on > > maintainers to apply more crap. > > I agree here. That's not the point. The idea is that for things > that -are- approved by their respective maintainers, to get some > integration testing and ironing of those mechanical bugs so that > by the time they hit mainstream, they don't break bisection among > others. This is certainly doable for agreeable features - which is the bulk - and it is being done. But this is a catch-22 for _controversial_ new features - which perfcounters clearly was, in case you turned off your lkml subscription ;-) And if you hit that build breakage during bisection you can do: git cherry-pick e14112d Also, you seem to brush off the notion that far more bugs slip through linux-next than get caught by it. So if you think linux-next matters in terms of _regression_ testing, the numbers dont seem to support that notion. This particular incident does support that notion though, granted - but it's taken out of context IMHO: In terms of test coverage, at least for our trees, less than 1% of the bugs we handle get reported in a linux-next context - and most of the bugs that get reported (against say the scheduler tree) are related to rare architectures. In fact, i checked, there were _zero_ x86 bugs reported against linux-next and solved against it between v2.6.30-rc1 and v2.6.30: git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/ Doing it over the full cycle shows one commit altogether - a Xen build failure. In fact, i just checked the whole stabilization cycle for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were only 5 linux-next originated patches, most of them build failures. I did this by looking at all occurances of 'next', in all commit logs: git log --grep=next -i v2.6.30-rc1..v2.6.30 and then manually checking the context of all 'next' matches and counting the linux-next related commits. So lets be generous and say that because some people dont put the bug report originator into the changelog it was four times as many, 20 - but that's still dwarved by the sheer amount of post-rc1 changes: thousands of changes and hundreds of regressions. linux-next is mostly useful (to me at least) not for the cross-builds it does, but in terms of mapping out upcoming conflicts - which also drives early detection of problematic patches and problematic conflicts. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
