From: Andrew de Quincey <adq_dvb@lidskialf.net>
To: Adrian Bunk <bunk@stusta.de>
Cc: David Lang <dlang@digitalinsight.com>,
Arnaud Patard <apatard@mandriva.com>, Greg KH <gregkh@suse.de>,
linux-kernel@vger.kernel.org, stable@kernel.org
Subject: Re: automated test? (was Re: Linux 2.6.17.7)
Date: Wed, 26 Jul 2006 15:39:49 +0100 [thread overview]
Message-ID: <200607261539.50492.adq_dvb@lidskialf.net> (raw)
In-Reply-To: <20060726142932.GE23701@stusta.de>
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....
next prev parent reply other threads:[~2006-07-26 14:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-25 3:42 Linux 2.6.17.7 Greg KH
2006-07-25 3:43 ` Greg KH
2006-07-25 9:55 ` Arnaud Patard
2006-07-25 10:23 ` Andrew de Quincey
2006-07-25 16:47 ` automated test? (was Re: Linux 2.6.17.7) David Lang
2006-07-25 16:56 ` Arjan van de Ven
2006-07-25 17:07 ` Michael Krufky
2006-07-25 18:42 ` Jean Delvare
2006-07-25 19:26 ` Andrew de Quincey
2006-07-25 21:20 ` Matthias Andree
2006-07-25 21:28 ` David Lang
2006-07-25 20:10 ` Arnaud Patard
2006-07-26 13:02 ` Adrian Bunk
2006-07-26 14:10 ` Andrew de Quincey
2006-07-26 14:29 ` Adrian Bunk
2006-07-26 14:39 ` Andrew de Quincey [this message]
2006-07-26 15:00 ` Adrian Bunk
2006-07-26 15:07 ` Andrew de Quincey
2006-07-26 17:11 ` David Lang
2006-07-26 17:15 Chuck Ebbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200607261539.50492.adq_dvb@lidskialf.net \
--to=adq_dvb@lidskialf.net \
--cc=apatard@mandriva.com \
--cc=bunk@stusta.de \
--cc=dlang@digitalinsight.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).