From: Mark Gross <mgross@linux.intel.com>
To: Dave Airlie <airlied@gmail.com>, Jesper Juhl <jesper.juhl@gmail.com>
Cc: Chris Friesen <cfriesen@nortel.com>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?
Date: Fri, 15 Jul 2005 14:39:22 -0700 [thread overview]
Message-ID: <200507151439.22594.mgross@linux.intel.com> (raw)
In-Reply-To: <21d7e997050714191666656d5@mail.gmail.com>
On Thursday 14 July 2005 19:16, Dave Airlie wrote:
> > That, of course, you cannot do. But, you can regression test a lot of
> > other things, and having a default test suite that is constantly being
> > added to and always being run before releases (that test hardware
> > agnostic stuff) could help cut down on the number of regressions in
> > new releases.
> > You can't test everything this way, nor should you, but you can test
> > many things, and adding a bit of formal testing to the release
> > procedure wouldn't be a bad thing IMO.
>
> But if you read peoples complaints about regression they are nearly
> always to do with hardware that used to work not working any more ..
> alps touchpads, sound cards, software suspend.. so these people still
> gain nothing by you regression testing anything so you still get as
> many reports.. the -rc series is meant to provide the testing for the
> release so nothing really big gets through (like can't boot from IDE
> anymore or something like that)....
>
I've seen large labs of lots of different systems used for dedicated testing
of products I've worked on in the past. The validation folks held the keys
to the build and if a change got in that broke on an important OEM's
hardware, then everything stops until that change is either fixed or backed
out.
It aint cheap. In open source we are attempting to simulate this, but we
don't simulate the control of the validation leads.
> Dave.
--
--mgross
BTW: This may or may not be the opinion of my employer, more likely not.
next prev parent reply other threads:[~2005-07-15 21:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200507140912.22532.mgross@linux.intel.com.suse.lists.linux.kernel>
2005-07-15 0:38 ` Why is 2.6.12.2 less stable on my laptop than 2.6.10? Andi Kleen
2005-07-15 1:45 ` Jesper Juhl
2005-07-15 2:02 ` Chris Friesen
2005-07-15 2:06 ` Jesper Juhl
2005-07-15 2:09 ` Andi Kleen
2005-07-15 21:33 ` Mark Gross
2005-07-15 2:16 ` Dave Airlie
2005-07-15 21:39 ` Mark Gross [this message]
2005-07-15 2:09 ` Dave Jones
2005-07-15 21:47 ` Mark Gross
2005-07-15 22:19 ` Dave Jones
2005-07-15 22:25 ` David Lang
2005-07-15 23:14 ` Rik van Riel
2005-07-18 21:14 ` Mark Gross
2005-07-19 10:12 ` Paolo Ciarrocchi
2005-07-15 2:09 ` Parag Warudkar
2005-07-15 2:14 ` Andi Kleen
2005-07-15 13:32 ` Alan Cox
2005-07-14 16:12 Mark Gross
2005-07-14 23:55 ` Andrew Morton
2005-07-15 8:45 ` Pavel Machek
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=200507151439.22594.mgross@linux.intel.com \
--to=mgross@linux.intel.com \
--cc=airlied@gmail.com \
--cc=ak@suse.de \
--cc=cfriesen@nortel.com \
--cc=jesper.juhl@gmail.com \
--cc=linux-kernel@vger.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