linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
	paulus@samba.org, Linus <torvalds@linux-foundation.org>
Subject: Re: linux-next: origin tree build failure
Date: Fri, 12 Jun 2009 23:29:57 +1000	[thread overview]
Message-ID: <1244813397.7172.156.camel@pasglop> (raw)
In-Reply-To: <1244812224.7172.146.camel@pasglop>

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.

  reply	other threads:[~2009-06-12 13:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12  0:24 linux-next: origin tree build failure Stephen Rothwell
2009-06-12  0:53 ` Paul Mackerras
2009-06-12  1:00 ` Benjamin Herrenschmidt
2009-06-12  9:20   ` Ingo Molnar
2009-06-12  9:33     ` Benjamin Herrenschmidt
2009-06-12  9:43       ` Peter Zijlstra
2009-06-12  9:55         ` Ingo Molnar
2009-06-12  9:57         ` Benjamin Herrenschmidt
2009-06-12 12:53       ` Ingo Molnar
2009-06-12 13:10         ` Benjamin Herrenschmidt
2009-06-12 13:29           ` Benjamin Herrenschmidt [this message]
2009-06-12 13:49             ` Ingo Molnar
2009-06-12 14:06               ` Benjamin Herrenschmidt
2009-06-12 14:11                 ` Ingo Molnar
2009-06-12 14:23                   ` Benjamin Herrenschmidt
2009-06-13  5:06                   ` Stephen Rothwell
2009-06-12 13:44           ` Ingo Molnar
2009-06-12 13:56             ` Benjamin Herrenschmidt
2009-06-12 14:07               ` Ingo Molnar
2009-06-12 14:19                 ` Benjamin Herrenschmidt
2009-06-13  4:54             ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2010-01-11 23:58 Stephen Rothwell
2010-01-12  0:29 ` Joakim Tjernlund
2010-01-12 12:38 ` Joakim Tjernlund
2009-06-19  6:30 Stephen Rothwell
2009-01-11 23:48 Stephen Rothwell
2009-01-12  0:10 ` Benjamin Herrenschmidt
2009-01-12  9:05   ` Ingo Molnar
2009-01-12  9:24     ` Stephen Rothwell
2009-01-12  9:32       ` Ingo Molnar
2009-01-13 16:31         ` Stephen Rothwell
2009-01-12  9:49     ` Michael Ellerman
2009-01-12 10:44       ` Ingo Molnar
2008-12-29  0:00 Stephen Rothwell
2008-07-25  0:30 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1244813397.7172.156.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).