linux-kernel - Re: [BUG] New Kernel Bugs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Nov 2007 16:24:32 +0100
From:	"Giacomo A. Catenazzi" <cate@...eee.net>
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

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.


As a long time kernel tester, I see some problem with the
newer "new development model". In the short merge windows,
after to much time, there are to many patches.
So there are problem to bisect bugs, and to have attention
of developers. My impression is that in a week there are
many more messages in lkml and to much bugs to be
handled in these few days.

I've two proposal:

- better patch quality. I would like that every commit
would compile. So an automatic commit test and public
blames could increase the quality of first commits.
[bisecting with non compilable point it is not a trivial
task]

- a slow down the patch inclusion on the merge windows
(aka: not to much big changes in the first days).
As tester I prefer that some big changes would be
included in a "secondary window" (pre o rc release),
in an other period as the big patch rush.

ciao
	cate
-
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/