* James Bottomley <[email protected]> wrote:
> On Wed, 2007-11-14 at 11:56 -0800, David Miller wrote:
> > From: Ingo Molnar <[email protected]>
> > 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.
> >
> > People who want to manage bugs know what list to look on and contact
> > about problems.
> >
> > Dumping even more crap on lkml is not the answer.
>
> I agree totally with David, and this goes for SCSI too. If it's not
> reported on linux-scsi, there's a significant chance of us missing the
> bug report. The fact that some people notice bugs go past on LKML and
> forward them to linux-scsi is a happy accident and not necessarily
> something to rely on.
>
> LKML has 10-20x the traffic of linux-scsi and a much smaller signal to
> noise ratio. Having a specialist list where all the experts in the
> field hangs out actually enhances our ability to fix bugs.
you are actually proving my point. People have to scan lkml for SCSI
regressions _anyway_, because otherwise _you_ would miss them. In the
case a user is fortunate enough to realize that a regression is SCSI
related, and he is lucky enough to pre-select the SCSI mailing list in
the first go, he might get a fix from you. That already reduces the
number of useful bugreports by about an order of magnitude.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
