lkml.org 
[lkml]   [2008]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on latest -git

* David Miller <davem@davemloft.net> wrote:

> From: Ingo Molnar <mingo@elte.hu>
> Date: Mon, 21 Apr 2008 10:22:54 +0200
>
> > * David Miller <davem@davemloft.net> wrote:
> >
> > > You haven't cared about how I push my trees to Linus for years,
> > > why is it a problem all of a sudden?
> >
> > the answer is simple, and it has nothing to do with you or with
> > networking at all: i'm maintaining about 10 times more code (and
> > more commits) than before.

<complete quote>
> > That means i'm signing off on more than 1000 commits per release,
> > and i'm exposed in a magnified way to other people's trees. [...]
</complete quote>

> Then, I can only conclude what several others have also concluded,
> that you've taken on x86 maintainence purely so that you can berate
> other subsystem maintainers who don't do things up to your
> specifications and standards.
>
> And frankly Ingo, that sucks.
>
> Instead of discussing things with people, you get up every morning and
> shoot off your randconfig nuclear bombs at your targets. It's what
> you've done all weekend long and it's very much NOT appreciated.

David, your argument is getting rather surreal and unjust.

in case you havent been following us on lkml lately, we've been doing
these randconfig tests (and have been reporting failures) for the last
6+ months almost non-stop. Initially it was rather hard to do - i
carried dozens of patches at times to keep the test humping along.

That shrunk within 1-2 months and these days this test generally works
fine day over day, night over night - with the merge window being an
(expected) small hickup. There's nothing new about it and if there's
anything nuclear here it's your accusations :-(

in hindsight i'm particularly happy that the test creates a random
sample because that way i can have no influence _at all_ about what kind
of bug gets found, so it is plain obvious that:

- its not about berating other maintainers
- its not about proving i do a better job

if you got 5 networking bugreports from me in short succession that is
simply so because they triggered in such short succession!

Also, because it's a random sample, we can make reliable observations
about the bug patterns - like it or not. That is _good_, because it
gives a metric without much (or any) subjective bias. Do you regard it
inappropriate to make any observations about the patterns of bugs we
find and report?

So IMO there's absolutely no objective reason for you to be upset about
_me_ - i'm just running a test that generates random kernels and i
report failures as i get them and observe patterns and annoyances while
doing so.

And i dont even understand your argument that basing and testing our
trees against latest -git is somehow wrong and that we should base our
trees against linux-next or -mm - you dont base your trees against them
either, and for similarly obvious reasons i suspect, right?

> The build failure knowledge is appreciated, however the reason you are
> reporting them is not. Why do we need to know that your automated
> tools have found 5 networking build failures "so far" over the
> weekend? That number is relative to what, exactly? [...]

My "so far" comment was based on the simple fact that these tests are
running non-stop and are continuously finding new bugs - and that the
last 5 bugs that triggered were networking. In my experience, if 5 build
bugs trigger in relatively short succession in a random sample, in 2500
new commits (out of which ~1000 are networking), then more might be
there as well - just harder to trigger.

[ btw., today seems to be a better day finally: after excluding that
minor SCTP complication from the test space, 116 kernels built and
booted up fine in a row, so far. ]

Ingo


\
 
 \ /
  Last update: 2008-04-21 13:17    [W:0.080 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site