lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 13 Nov 2007 17:34:11 -0700
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Mark Lord <liml@....ca>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>, 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

On Tuesday 13 November 2007 07:08, Mark Lord wrote:
> Ingo Molnar wrote:
> ..
>
> > This is all QA-101 that _cannot be argued against on a rational basis_,
> > it's just that these sorts of things have been largely ignored for
> > years, in favor of the all-too-easy "open source means many eyeballs and
> > that is our QA" answer, which is a _good_ answer but by far not the most
> > intelligent answer! Today "many eyeballs" is simply not good enough and
> > nature (and other OS projects) will route us around if we dont change.
>
> ..
>
> QA-101 and "many eyeballs" are not at all in opposition.
> The latter is how we find out about bugs on uncommon hardware,
> and the former is what we need to track them and overall quality.
>
> A HUGE problem I have with current "efforts", is that once someone
> reports a bug, the onus seems to be 99% on the *reporter* to find
> the exact line of code or commit.  Ghad what a repressive method.

This is the only method that scales.

Developer has only 24 hours in each day, and sometimes he needs to eat,
sleep, and maybe even pay attention to e.g. his kids.

But bug reporters are much more numerous and they have more
hours in one day combined.

BUT - it means that developers should try to increase user base,
not scare users away.

> And if the "developer" who broke the damn thing, or who at least
> "claims" to be supporting that code, cannot "reproduce" the bug,
> they drop it completely.

Developer should let reporter know that reporter needs to help
a bit here. Sometimes a bit of hand holding is needed, but it
pays off because you breed more qualified testers/bug reporters.

> Contrast that flawed approach with how Linus does things..
> he thinks through the symptoms, matches them to the code,
> and figures out what the few possibilities might be,
> and feeds back some trial balloon patches for the bug reporter to try.
>
> MUCH better.
>
> And remember, *I'm* an old-time Linux kernel developer.. just think about
> the people reporting bugs who haven't been around here since 1992..

Yes. Developers should not grow more and more unhelpful
and arrogant towards their users just because inexperienced
users send incomplete/poorly written bug reports.
They need to provide help, not humiliate/ignore.

I think we agree here.
--
vda
-
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ