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

quoted text
> From: Ingo Molnar <mingo@elte.hu>
> Date: Wed, 14 Nov 2007 15:08:47 +0100
> 
> > In fact this thread is the very example: David points out that on netdev 
> > some of those bugs were already discussed and resolved. Had it been all 
> > on lkml we'd all be aware of it.
> 
> That's a rediculious argument.
> 
> One other reason these bugs are resolved, is that the networking 
> developers only need to subscribe to netdev and not have to listen to 
> all the noise on lkml.

what noise? If someone really wants networking discussions only, use 
this procmail rule:

  :0 HBc
          * .*net: *
          sched-patches

to separate it into an extra folder and use "net: " as an agreed upon 
Subject line if you really want to narrow things down. (But there would 
still be all the other mail just in case the developer has to look at 
the wider picture. There would be no "I'm only subscribed to netdev" 
excuse. )

but there should still be one central repository for all kernel 
discussions - just like there is one central repository for all kernel 
code.

quoted text
> People who want to manage bugs know what list to look on and contact 
> about problems.

i think that's the problem. Developers (and here i dont mean you) who
want to do "development only", without being exposed to the global state
of the kernel and without being exposed to bugs. I think that's the
basic mindset difference. That is one of the factor that is causing
assymetric allocation of developers and the increasing detachment from
reality.

quoted text
> Dumping even more crap on lkml is not the answer.

that "crap" that i'd like to see dumped upon lkml would be netdev 
traffic mainly - most of the other kernel development lists (and i'm 
subscribed to many of them) are low-traffic. netdev is the main reason 
why we cannot do a "one common discussion forum" approach.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html