linux-kernel - Re: Reporting bugs and bisection

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]

Message-ID: <alpine.DEB.1.10.0804152042320.15483@asgard>
Date:	Tue, 15 Apr 2008 20:53:27 -0700 (PDT)
From:	david@...g.hm
To:	David Newall <davidn@...idnewall.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Michael Kerrisk <mtk.manpages@...il.com>,
	James Morris <jmorris@...ei.org>,
	Al Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Willy Tarreau <w@....eu>,
	Stephen Clark <sclark46@...thlink.net>,
	Evgeniy Polyakov <johnpol@....mipt.ru>,
	Tilman Schmidt <tilman@...p.cc>, Valdis.Kletnieks@...edu,
	Mark Lord <lkml@....ca>, David Miller <davem@...emloft.net>,
	jesper.juhl@...il.com, yoshfuji@...ux-ipv6.org, jeff@...zik.org,
	linux-kernel <linux-kernel@...r.kernel.org>, git@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: Reporting bugs and bisection

On Wed, 16 Apr 2008, David Newall wrote:

> Rafael J. Wysocki wrote:
>> Well, even if someone introduces bugs relatively frequently, but then also
>> works with the reporters and fixes the bugs timely, it's about okay IMO.
>>
> This really is not okay.  Even if bugs are fixed a version or two later,
> the impact those bugs have on users makes the system look bad and drives
> them away.  We do not, I believe, want Linux to top the list for "most
> bugs".  It's unprofessional, unreliable and quite undesirable.

timely frequently means the code was merged in -rc1/2 and was fixed before 
the final release of the same version.

given the huge variety of hardware and workloads, it's just too easy for 
there to be cases where any trade-off you make (code size, performance, 
memory usage, common case definitions) can turn around and bite you. In 
addition frequently hardware doesn't work quite the way the design specs 
say that it should (completely ignoring the fact that many drivers are 
reverse engineered). what's most important is that when a case shows up it 
gets addressed promptly

I'd rather have a developer/maintainer who introduces and fixed 100 bug, 
but fixes them promptly, as opposed to one who only introduces one bug, 
but refuses to consider fixing the code 'because they don't make mistakes 
like that' (u.sadly a common attitude from people who produce very 
good code much of the time)

best of all is a developer/maintainer who writes very good code and is 
willing to accept the fact that they make mistakes and fixes the code 
promptly, but those people are extremely rare, and usually they emerge 
from the pool of people who make more mistakes and fix them promptly, 
which is an added reason I'm more tolerant of that group.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/