From: Chuck Ebbert <76306.1226@compuserve.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: Arnaud Patard <apatard@mandriva.com>,
David Lang <dlang@digitalinsight.com>,
Andrew de Quincey <adq_dvb@lidskialf.net>,
Greg KH <greg@kroah.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-stable <stable@kernel.org>
Subject: Re: automated test? (was Re: Linux 2.6.17.7)
Date: Wed, 26 Jul 2006 13:15:41 -0400 [thread overview]
Message-ID: <200607261318_MC3-1-C623-96BB@compuserve.com> (raw)
In-Reply-To: <20060726142932.GE23701@stusta.de>
On Wed, 26 Jul 2006 16:29:32 +0200, Adrian Bunk wrote:
> 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.
The problem with the current method of releasing patch candidates is
that it's too hard to test them. I would suggest:
1. In addition to posting all the patches separately to L-K,
post a combined patch. Have it change the makefile so it
says 2.6.X.Y-rcZ; that way if an oops gets posted we know
what the codebase was. If the patch is too big, put it
on a website.
2. Make the separate patches available on a website in Quilt
format like Andrew does with -mm. (Just like (1) above,
make sure it changes the kernel version.) This makes it
easier for testers to fix individual patches.
3. Keep posting -rc's until nobody reports problems.
It's easy to generate (1) from (2):
a. Untar the quilt patchset into the new directory.
Make sure the old and new dirs are subdirectories
of some common directory, are identical and they
are dist-clean.
b. mv broken-out patches
c. quilt push -a -q
d. cd ..
e. diff -uprN -X ignorefiles old new >old.new.patch
-- ignorefiles contains two lines:
.pc
patches
--
Chuck
next reply other threads:[~2006-07-26 17:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-26 17:15 Chuck Ebbert [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-07-25 3:42 Linux 2.6.17.7 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
2006-07-26 15:00 ` Adrian Bunk
2006-07-26 15:07 ` Andrew de Quincey
2006-07-26 17:11 ` David Lang
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=200607261318_MC3-1-C623-96BB@compuserve.com \
--to=76306.1226@compuserve.com \
--cc=adq_dvb@lidskialf.net \
--cc=apatard@mandriva.com \
--cc=bunk@stusta.de \
--cc=dlang@digitalinsight.com \
--cc=greg@kroah.com \
--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
all inboxes | Powered by JetHome®