linux-kernel - Re: linux-next: origin tree build failure

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]

Message-Id: <1244813397.7172.156.camel@pasglop>
Date:	Fri, 12 Jun 2009 23:29:57 +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 23:10 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:

> 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.

Let me add a little bit more background to my reasoning here and why I
think having this integration testing step is so valuable...

It all boils down to bisection and having a bisectable tree.

Yes, I hate bisecting and I'm sure you are the same. It's a major PITA
and in most cases, I'm better off tracking down the actual bug and then
finding how it came into being.

However, what the ability to have a reasonably bisectable tree buys us
is all those users, testers, good wills, etc... people who do not have
the knowledge, skill, familiarity with the code etc... to track the bug
down, to be able to still find out what precise patch brought that pesky
regression that doesn't happen on anybody else machine, and thus brings
us some useful material to work with when we cannot reproduce the exact
same setup on our own machines.

Yes, I and I'm sure you can deal with a bisection breakage caused by a
minor screweup like the one we are talking about. But our testers often
can't and will just give up.

It has -nothing- to do with whether the patches are controversial or
not, it is purely about trying to make sure that things going into linus
tree had at least a few days of churning by the various involved parties
to try to get closer to the graal of a fully bisectable tree.

At least that's how I see it.

Now, we may disagree and I'm happy to discuss that more around a beer at
next KS, and to some extent, what is done is done, and if we screwed up
with -next vs. perfmon, then so be it and let's learn from our mistakes,
but I believe it makes a lot of sense to have that staging area that
helps us making sure that within a merge window with gazillion things
being merged pretty much at once, we keep this ability for our users and
testers to track down which individual patch broke something.

Cheers,
Ben.

--
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/