linux-kernel - [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

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 11:41:36 +0200
From:	Michal Piotrowski <michal.k.k.piotrowski@...il.com>
To:	Adrian Bunk <bunk@...sta.de>
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: [PATCH]  (Re: regression tracking (Re: Linux 2.6.21))

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

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Signed-off-by: Michal Piotrowski <michal.k.k.piotrowski@...il.com>

--- linux-work-clean/Documentation/SubmitChecklist	2007-06-17 11:18:37.000000000 +0200
+++ linux-work/Documentation/SubmitChecklist	2007-06-17 11:29:26.000000000 +0200
@@ -90,3 +90,8 @@ kernel patches.
     patch style checker prior to submission (scripts/checkpatch.pl).
     You should be able to justify all violations that remain in
     your patch.
+
+
+
+If the patch introduces a new regression and this regression was not fixed
+in seven days, then the patch will be reverted.
-
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/