[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071114204840.GB20606@elte.hu>
Date: Wed, 14 Nov 2007 21:48:40 +0100
From: Ingo Molnar <mingo@...e.hu>
To: David Miller <davem@...emloft.net>
Cc: rdunlap@...otime.net, akpm@...ux-foundation.org,
protasnb@...il.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, alsa-devel@...a-project.org,
linux-ide@...r.kernel.org, linux-pcmcia@...ts.infradead.org,
linux-input@...ey.karlin.mff.cuni.cz,
bugme-daemon@...zilla.kernel.org
Subject: Re: [BUG] New Kernel Bugs
* David Miller <davem@...emloft.net> wrote:
> From: Ingo Molnar <mingo@...e.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.
> 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.
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists