linux-kernel - Re: automated test? (was Re: Linux 2.6.17.7)

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:	Wed, 26 Jul 2006 15:39:49 +0100
From:	Andrew de Quincey <adq_dvb@...skialf.net>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	David Lang <dlang@...italinsight.com>,
	Arnaud Patard <apatard@...driva.com>, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, stable@...nel.org
Subject: Re: automated test? (was Re: Linux 2.6.17.7)

On Wednesday 26 July 2006 15:29, Adrian Bunk wrote:
> On Wed, Jul 26, 2006 at 03:10:02PM +0100, Andrew de Quincey wrote:
> > On Wednesday 26 July 2006 14:02, Adrian Bunk wrote:
> >...
> >
> > > What bothers me more is that noone tested this patch against the kernel
> > > it was applied against.
> > >
> > > The submitter didn't test it works (he didn't even test the
> > > compilation).
> >
> > Yes I did - I didn't test the final generated patch unfortunately since I
> > assumed it worked. The kernel I _meant_ to diff against worked perfectly
> > :(
>
> Sorry if this was wrong, it wasn't meant against you personally.
>
> Things do go wrong. That's life.
> And you aren't the first person who sent a patch that broke the
> compilation of the next -stable kernel.

thanks. I feel a little bit better :)

> The real problem is:
> How do we get some testing coverage of -stable kernels by users to catch
> issues?
> And compile errors are the least of my worries.

Yeah - I believe some people did test the DVB -stable patches, but obviously 
without the budget-av driver compile option enabled, so it didn't compile 
that code. DVB supports quite a few cards, so its easy to accidentally leave 
off one of the options when doing a mass compile of all drivers.

The only thing I can think of would be to require -stable patch submitters to 
supply a list of CONFIG options that must be on to enable compilation of the 
new code so people know exactly how to enable it for testing... but obviously 
since those would be manually specified, they can be wrong too. But at least 
it would show they'd thought about it a bit....
-
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/