All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Kegel <dank@kegel.com>
To: "Timothy D. Witham" <wookie@osdl.org>
Cc: Luigi Genoni <kernel@Expansa.sns.it>,
	Mike Galbraith <mikeg@wen-online.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	stp@osdl.org
Subject: Re: Regression testing of 2.4.x before release?
Date: Sun, 11 Nov 2001 22:24:27 -0800	[thread overview]
Message-ID: <3BEF6B1B.1E077ED9@kegel.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0111041955290.30596-100000@Expansa.sns.it>  <3BE5F0B5.52274D07@kegel.com> <1004978377.1226.22.camel@wookie-laptop.pdx.osdl.net>

"Timothy D. Witham" wrote:
> ...
>   I agree having the users run their applications and under their usage
> model is a very good way of testing code drops.  Dan, I think that what
> you are trying to say is that it might be a good idea to take a group
> of tests and make them the standard set of "pass/fail" that people
> should look to before doing their own testing.

More like a safety net.  It'd help make sure we didn't forget something
obvious.
>...
>   Regression type pass/fail tests don't tend to have the benchmark
> optimization issue but like any test they usually only find the
> problems that you either already have had in the past or that are
> obvious.  Not complete but they should be dynamic environment that
> things are being added to all the time.  Also the nice part about a
> knows series of tests is that if a problem pops up it is much
> easier to reproduce for debugging purposes.

Yep.

> > 2. The STP at OSDLab seems like a great resource that we might be able
> > to leverage to solve the problem Alan points out.
> 
>   The nice part about the way that STP was designed is that it is
> extensible.  If somebody comes up with another test we can add it.
> If we need to add additional equipment to get the run times down
> to a usable level then that is easy to do also.
> 
> > I'm not suggesting anyone do any less testing.  Just the opposite;
> > if we set things up properly with the STP, we might be able to run
> > many more tests before each final release.
> 
>   We are in the process of setting up the Kernel STP to automatically
> grab the Linus and -ac kernels and run the full setup.  This will
> do part of what Dan is asking for and it will also allow people who
> are looking to supply patches a baseline for there patch testing.

That's super!  Thanks, Tim!

At some point it might be nice to also use the STP to help
speed gcc 3 development, too.  (I personally am really
looking forward to the day when I can use the same compiler
for both c++ and kernel.)

- Dan

  reply	other threads:[~2001-11-12  6:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.33.0111040832060.364-100000@mikeg.weiden.de>
2001-11-04 17:58 ` Regression testing of 2.4.x before release? Dan Kegel
2001-11-04 19:09   ` Luigi Genoni
2001-11-05  1:51     ` Dan Kegel
2001-11-05 16:39       ` Timothy D. Witham
2001-11-12  6:24         ` Dan Kegel [this message]
2001-11-12 19:07           ` Timothy D. Witham
2001-11-13  4:53             ` Dan Kegel
2001-11-13 22:00               ` STP for automated GCC testing (was Re: Regression testing of 2.4.x beforerelease?) Bryce Harrington
2002-01-10 23:50           ` Regression testing of 2.4.x before release? Daniel Phillips
2002-01-10 23:50           ` Daniel Phillips
2002-01-12  0:04             ` M. Edward (Ed) Borasky
2002-01-12  0:29               ` eddantes
2002-01-12  0:34               ` [OT] " Kurt Garloff
2001-11-04  7:03 Dan Kegel
2001-11-04  7:15 ` Ted Deppner
2001-11-04 12:04   ` Tahar
2001-11-04 17:27     ` Ted Deppner
2001-11-04 18:41     ` Luigi Genoni

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=3BEF6B1B.1E077ED9@kegel.com \
    --to=dank@kegel.com \
    --cc=kernel@Expansa.sns.it \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikeg@wen-online.de \
    --cc=stp@osdl.org \
    --cc=wookie@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.