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:	Sun, 17 Jun 2007 14:45:08 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Oleg Verych <olecom@...wer.upol.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Diego Calleja <diegocg@...il.com>,
	Chuck Ebbert <cebbert@...hat.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH]  (Re: regression tracking (Re: Linux 2.6.21))

On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Adrian Bunk pisze:
>> On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
>>> ...
>>> [Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
>>> few FireWire driver users run -rc kernels".]
>> Getting more people testing -rc kernels might be possible, and I don't 
>> think it would be too hard. And not only FireWire would benefit from this, 
>> remember e.g. that at least 2 out of the last 5 kernels Linus released 
>> contained filesystem corruption regressions.
>> The problem is that we aren't able to handle the many regression reports 
>> we get today, so asking for more testing and regression reports today 
>> would attack it at the wrong part of the chain.
>> Additionally, every reported and unhandled regression will frustrate the 
>> reporter - never forget that we have _many_ unhandled bug reports 
>> (including but not limited to regression reports) where the submitter 
>> spent much time and energy in writing a good bug report.
>> If we somehow gain the missing manpower for debugging regressions we can 
>> actively ask for more testing. Missing manpower (of people knowing some 
>> part of the kernel well) for debugging bug reports is IMHO the one big 
>> source of quality problems in the Linux kernel. If we get this solved, 
>> things like getting more testers for -rc kernels will become low hanging 
>> fruits.
>
> Adrian, I agree with _all_ your points.
>
> I bet that developers will hate me for this.
>
> Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or 
even worse, a big infrastructure patch exposing a latent old bug in some 
completely different area of the kernel.

And we should be aware that reverting is only a workaround for the real 
problem which lies in our bug handling.

> Regards,
> Michal
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ