[BUG] New Kernel Bugs

[Ingo Molnar]

* Randy Dunlap <rdunlap at xenotime.net> wrote:

> > so please stop this "too busy and too noisy" nonsense already. It 
> > was nonsense 10 years ago and it's nonsense today. In 10 years the 
> > kernel grew from a 1 million lines codebase to an 8 million lines 
> > codebase, so what? Deal with it and be intelligent about filtering 
> > your information influx instead of imposing a hard pre-filtering 
> > criteria that restricts intelligent processing of information.
> 
> So you have a preferred method of handling email.  Please don't force 
> it on the rest of us.

actually, posting to lkml is the preferred method of handling 
development for like 70% of all Linux kernel activities. It is _YOU_ who 
is the sore thumb sticking out, it is you who is forcing people to Cc: 
around various stupid fractured lists for no good reason. You dont have 
to read all of lkml, just like you dont read all of netdev either.

once someone decides to work on Linux, information should be 
fundamentally opt-out, not opt-in. And there should be a central place 
for people to go to. The "Subject:" line is enough of a filter key - in 
fact it's _far superior_ to the forced separation of topics that you 
advocate! Fact is, many regressions happen because they were posted to 
the wrong list and got ignored or under-handled. I claim that we'd have 
a much higher quality kernel if we had a single central mailing list 
instead of these elitist fractured lists. Every kernel topic would have 
global visibility, and it would be trivially easy to get the interest of 
other people, across subsystems.

damn, THINK ABOUT IT instead of just ignorantly dismissing my points 
without even answering them... Often when someone writes to the wrong 
list and he is told "wrong list", he'd have to repost to the "right 
list". Lots of extra bounces for the tester for _NO GOOD REASON_. All 
just because a few developers are too lazy to filter the lkml subjects 
for their main topic of interest.

I claim that we have far larger lack of testing resources than we have a 
lack of development resources. So we might as well set up our mailing 
lists to favor information sharing, instead of imposing this insane 
separation of lists that some subsystems still insist on. We can 
evidently throttle development activities by forcing _every subsystem_ 
to lkml and exposing them to the harsh combined realities of all the 
crap that we are are writing. Life might look nice and easy on an 
isolated list, and it's sure convenient not being exposed to ... users. 

THAT is our main problem, not your bogus "lkml has too much traffic" 
argument.

	Ingo