From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Linus <torvalds@linux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
paulus@samba.org, ppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: linux-next: origin tree build failure
Date: Fri, 12 Jun 2009 23:56:16 +1000 [thread overview]
Message-ID: <1244814976.7172.164.camel@pasglop> (raw)
In-Reply-To: <20090612134428.GC32105@elte.hu>
On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
> 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 ;-)
I didn't :-) My point here is that Linus can make a decision with an
email -before- merging so that -next gets a chance, at least for a
couple of days, to do the integration testing once the controversy has
been sorted by his highness.
> And if you hit that build breakage during bisection you can do:
>
> git cherry-pick e14112d
Right, I can, you can, but can random tester who wants to track down
what his problem is ? I'm not sure...
> Also, you seem to brush off the notion that far more bugs slip
> through linux-next than get caught by it.
Less than without linux-next. We aren't perfect and no process will
solve everything. But this could have been easily avoided.
> 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.
But most obvious bugs will have been caught way before that, which
leaves the hard to catch ones or the configuration-specific ones. Those
will pass linux-next, I agree. But that isn't my point and that isn't
what linux-next will catch. What is will catch is that kind of really
simple mechanical problems, such as build breakage for other archs.
If perfcounters had been 1 or 2 days in -next before being merged, we
would have avoided that problem and made everybody's bisecting life
easier.
> 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:
No but Stephen caught a bunch of mechanical compile fails due to
integration problems.
> 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.
Yes, it does. The problem is that it helps -you- that way, but won't
help -us- vs. that kind of mechanical problems unless -you- also play
the game and get your stuff in there for a little while before merging
it :-)
Cheers,
Ben.
next prev parent reply other threads:[~2009-06-12 13:56 UTC|newest]
Thread overview: 102+ 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
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 [this message]
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-12 1:14 Stephen Rothwell
2010-01-12 1:26 ` Linus Torvalds
2010-01-12 2:32 ` Stephen Rothwell
2010-01-12 2:39 ` Stephen Rothwell
2010-01-13 0:14 ` Phillip Lougher
2010-01-13 2:55 ` Stephen Rothwell
2010-01-11 23:58 Stephen Rothwell
2010-01-12 0:29 ` Joakim Tjernlund
2010-01-12 12:38 ` Joakim Tjernlund
2009-12-24 0:54 Stephen Rothwell
2009-12-15 5:41 Stephen Rothwell
2009-12-15 8:07 ` Ingo Molnar
2009-12-15 13:01 ` Peter Ujfalusi
2009-12-15 14:53 ` Mark Brown
2009-12-15 17:27 ` Tony Lindgren
2009-12-15 22:45 ` Stephen Rothwell
2009-12-15 23:02 ` Linus Torvalds
2009-12-15 23:37 ` Stephen Rothwell
2009-12-16 9:30 ` Samuel Ortiz
2009-12-09 23:57 Stephen Rothwell
2009-11-30 23:10 Stephen Rothwell
2009-11-12 0:23 Stephen Rothwell
2009-10-09 7:50 Stephen Rothwell
2009-07-09 0:28 Stephen Rothwell
2009-06-25 1:13 Stephen Rothwell
2009-06-25 3:24 ` Baruch Siach
2009-06-25 4:12 ` Paul Mundt
2009-06-23 6:22 Stephen Rothwell
2009-06-23 10:13 ` Mark Brown
2009-06-19 6:30 Stephen Rothwell
2009-06-12 0:46 Stephen Rothwell
2009-04-14 7:34 Stephen Rothwell
2009-04-14 7:58 ` Jesper Nilsson
2009-04-14 4:43 Stephen Rothwell
2009-04-14 8:57 ` David Miller
2009-04-14 9:20 ` Heiko Carstens
2009-04-14 9:08 ` David Miller
2009-04-14 10:26 ` Stephen Rothwell
2009-04-08 3:28 Stephen Rothwell
2009-04-08 0:10 Stephen Rothwell
2009-03-30 0:55 Stephen Rothwell
[not found] <20090112104837.69feedec.sfr@canb.auug.org.au>
2009-01-12 0:10 ` Benjamin Herrenschmidt
2009-01-12 0:10 ` Benjamin Herrenschmidt
2009-01-12 0:10 ` Benjamin Herrenschmidt
[not found] ` <1231719015.22571.4.camel@pasglop>
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
2009-01-12 10:44 ` Ingo Molnar
2009-01-12 10:44 ` Ingo Molnar
2009-01-11 23:48 Stephen Rothwell
2009-01-11 23:48 Stephen Rothwell
2009-01-11 23:48 Stephen Rothwell
2008-12-29 0:43 Stephen Rothwell
2008-12-29 3:36 ` Roland Dreier
2008-12-29 3:44 ` Roland Dreier
2008-12-29 9:58 ` Aleksey Senin
2008-12-29 0:00 Stephen Rothwell
2008-12-28 23:51 Stephen Rothwell
2008-12-28 23:38 Stephen Rothwell
2008-12-29 0:31 ` Linus Torvalds
2008-10-16 0:35 Stephen Rothwell
2008-10-16 4:57 ` David Miller
2008-10-16 0:31 Stephen Rothwell
2008-10-16 12:58 ` Ralf Baechle
2008-10-14 22:59 Stephen Rothwell
2008-10-14 23:43 ` Linus Torvalds
2008-10-14 23:52 ` David Miller
2008-10-15 0:05 ` Mark Brown
2008-10-15 0:34 ` Linus Torvalds
2008-10-14 23:51 ` Linus Torvalds
2008-10-15 9:02 ` Alan Cox
2008-10-15 9:33 ` Ingo Molnar
2008-10-15 11:01 ` Mark Brown
2008-08-26 0:37 Stephen Rothwell
2008-08-18 0:01 Stephen Rothwell
2008-08-18 12:55 ` David Howells
2008-08-18 14:03 ` James Morris
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=1244814976.7172.164.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).