| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1244812224.7172.146.camel@pasglop> Date: Fri, 12 Jun 2009 23:10:24 +1000 From: Benjamin Herrenschmidt <benh@...nel.crashing.org> To: Ingo Molnar <mingo@...e.hu> Cc: Stephen Rothwell <sfr@...b.auug.org.au>, Linus <torvalds@...ux-foundation.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-kernel@...r.kernel.org, linux-next@...r.kernel.org, paulus@...ba.org, ppc-dev <linuxppc-dev@...ts.ozlabs.org> Subject: Re: linux-next: origin tree build failure On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote: > * Benjamin Herrenschmidt <benh@...nel.crashing.org> wrote: > linux-next has integration testing so that interactions between > maintainer trees are mapped and that architectures that otherwise > few people use get build-tested too (well beyond their practical > relevance, i have to add) - but there's little critical review done > in linux-next. Nor should it be the forum for that, it simply > contains way too much stuff and has a weird history format with > daily rebases that makes review hard and expensive in that form. I think you are mixing several issues. One is integration testing, one is the problem of remote architecture of subsystems testing... > 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. Yes, next is -not- the place to debate controversial features. That's not, I believe, why it was initiated (I may be wrong, Stephen will correct me if I am), but the way I see things is that stuff that is meant to be merged gets a chance to get some of that integration testing against all the other stuff that is also meant to be merged to limit the amount of clash and problems once we hit Linus tree. > And that is true even if it's a new feature that i happen to support > - as in this case - it sure would have been handy to have more > perfcounters test coverage, every little bit of extra testing helps. That doesn't invalidate my point. We are not talking about whether perfcounters is worth merging or not, testing more or not, but strictly, imho, about getting a chance (a couple of days at least) to do that integration testing and catch the simple issues like the one that triggered my initial rant -before- they hit mainline. To some extent, here, the issue is on Linus side and it's up to him (Hey Linus ! still listening ?) to maybe be more proactive at giving an ack or nack so that we can get a chance to do that final pass of ironing out the mechanical bugs before we hit the main tree. Cheers, Ben. > If linux-next wants to do that then it should be renamed to > something else and not called linux-next. > > Ingo > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@...r.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists