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: Sat, 19 Apr 2008 12:39:42 +0200
>
> I knew you were going to make a stink about this, and frankly Ingo I'm
> starting to get extremely irritated about your persistant nagging
> about how people should do this or that wrt. kernel development.
>
> I seem to see a lot of it because 1) I don't think pushing everything
> to lkml is the answer to everything and 2) I think the trees like -mm
> and linux-next take care of the scalability issues of watching the
> state of trees that will be merged to Linus in the future.

And i'd like to make one thing really clear, before we discuss anything
else. You seem to imply in your mail that i'm somehow picking on you.
I'm not - i try to be as unbiased in terms of picking subsystems that i
find bugs in as it gets: it's randconfig builds/bootups that selects the
test target, not me. I'd be the happiest camper if these discussions
werent happening at all. I'm not out here looking for bugs. Look at
lkml, i reported the bugs in the order and frequency as they were found
by the qa scripts.

Fact is that for the third straight day i cannot do meaningful overnight
testing of my trees because -git keeps spewing out build failures.

( And i cannot just change the QA scripts to skip over networking build
bugs. My build system _runs on the tested kernel_, to prove that the
kernel is reasonably self-hosting and to prove that the
user/developer, even if a kernel was buggy, would be able to download
a new kernel over the network and would be able to build a new kernel.
So if there's any build failure the whole test stops and i need to see
the exact nature of the failure myself. I found a handful of bugs
where there was no real build bug but a bug in the target kernel made
the build fail. Just two weeks ago i had a DMA bug that showed up as a
sporadic build error. )

Let me give you an example, for code neither of us maintains, maybe that
works better as an argument. I dont remember the last time when i
triggered _any_ VFS bug (build or runtime bug) - and it's a subsystem
that is larger and even more central one than networking. The VFS rate
of change (# of commits and diffstat) is comparably high as well:

$ git-rev-list v2.6.24..v2.6.25 fs/ | wc -l
929
$ git-diff v2.6.24..v2.6.25 fs/ | diffstat | tail -1
624 files changed, 27449 insertions(+), 16385 deletions(-)


$ git-rev-list v2.6.24..v2.6.25 net/ | wc -l
1389
$ git-diff v2.6.24..v2.6.25 net/ | diffstat | tail -1
654 files changed, 43514 insertions(+), 23357 deletions(-)

sure, there are crutial differences between the two codebases - but the
difference seems striking to me, in actual hands-on testing. Why is
that? Are the filesystem folks different due to the nature of their
code?

> 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. 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. And i still do what i did for the last 13 years of Linux
kernel hacking: when i see a problem i either fix it or i complain about
it so that it gets fixed. And when a problem stays unfixed i complain
louder. And i do all that in a loop ;-)

and i'd like to remind you of the following unfixed v2.6.25 networking
regression:

Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=10427
Subject : e1000e broke e1000
Submitter : Ingo Molnar <mingo@elte.hu>
Date : 2008-04-08 20:39 (13 days old)
References : http://lkml.org/lkml/2008/4/8/256
Patch : http://bugzilla.kernel.org/attachment.cgi?id=15704&amp;action=view

You pushed a stream of last-minute networking fixes upstream even in the
very last minutes of v2.6.25 but this one was either forgotten or not
deemed important enough. There was no followup i could see, the
discusssion just went dead with no resolution that i can see.

> Different people operate differently, and might have alternate
> approaches to insuring quality and smooth merging of the changes they
> manage. The only thing that really matters is that the people who
> push directly to Linus are trusted by him, and they won't disappear
> right after he pulls their changes in.
>
> You got a bug fix in 5 minutes after sending your email to the lists,
> and since you sent it to lkml anybody can find it, so I don't see what
> the big deal is.

for the last 3 days my own automated bug finding capacity is at 10% of
its normal throughput (it booted only 200 kernels, instead of 2000
kernels) - which is OK in early phases of the merge window, but you seem
to deny that i have any standing to argue development process issues.
:-/ Who has standing to argue with you in those issues, only Linus?

Ingo


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