Message-Id: <20080419.040945.13369499.davem@davemloft.net>
Date:	Sat, 19 Apr 2008 04:09:45 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	mingo@...e.hu
Cc:	linux-kernel@...r.kernel.org, kaber@...sh.net,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org
Subject: Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on
 latest -git

From: Ingo Molnar <mingo@...e.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.

You haven't cared about how I push my trees to Linus for years, why is
it a problem all of a sudden?

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.

> do you find this practice of private pull requests important? If not, 
> would it be difficult to Cc: lkml to routine pull requests?

Ingo, I don't tell you how to effectively do your job with x86
development.  So why don't we leave it at that, ok?

> > I always send my pull requests directly to Linus, CC:'ing Andrew.
> 
> that makes bugs harder to report and makes the flow of patches harder to 
> follow as well. Often (like in this case) i see it when a bug comes in 
> via a specific group of commits but i have no time to do a bisection. In 
> that case i'd like to report it to that pull request so i'd like to 
> reply to that pull on lkml.

Ingo, get off your high holy horse already.  It is your opinion that
bugs are harder to report.  You got a bug fix in 5 minutes by sending
it the people in the group of singoffs and CC:'ing lkml.  What the
heck more do you want? :-/

The way you see as the ideal isn't something you can just start
demanding of other people because it doesn't work optimally for you.

All of this networking stuff has been in linux-next and -mm for
several months.  And frankly it doesn't help anyone to spam ~5000 lkml
subscribers with a 128K sized merge request, which is how big this one
was.  In fact, as list owner for all of the vger lists, I'd probably
be processing a bunch of bounces as a result of such a posting.

If you want to start running your randconfig machinery on the
linux-next tree and -mm, that would be a great contribution for
keeping build regressions down to a healthy minimum before the merge
window opens up.

> As the number of subsystems increases, i suspect you agree with 
> me that this does not scale very well for bug reporters, correct?

That's why we have -mm and linux-next, to make it scale.

I'm not hiding anything, or operating in secrecy in an attempt to
thwart the productivity of other kernel developers.  My trees sync
daily into Andrew and Stephen Rothwell's trees, and every networking
patch goes through netdev.  Bugs aren't hard to report, send them
to the patch author and signoff emails, CC:'ing lkml and any other
list as you deem appropriate.

Ingo, I can't have a healthy relationship with you a fellow kernel
developer if every interaction we have with eachother these days is
about how you want me to change how I do my work.
--
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/

Powered by blists - more mailing lists