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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ