public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: Andi Kleen <ak@suse.de>, Mark Gross <mgross@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?
Date: Thu, 14 Jul 2005 22:09:12 -0400	[thread overview]
Message-ID: <20050715020912.GB22284@redhat.com> (raw)
In-Reply-To: <9a8748490507141845162c0f19@mail.gmail.com>

On Fri, Jul 15, 2005 at 03:45:28AM +0200, Jesper Juhl wrote:
 
 > > > The problem is the process, not than the code.
 > > > * The issues are too much ad-hock code flux without enough disciplined/formal
 > > > regression testing and review.
 > > 
 > > It's basically impossible to regression test swsusp except to release it.
 > > Its success or failure depends on exactly the driver combination/platform/BIOS
 > > version etc.  e.g. all drivers have to cooperate and the particular
 > > bugs in your BIOS need to be worked around etc. Since that is quite fragile
 > > regressions are common.
 > > 
 > > However in some other cases I agree some more regression testing
 > > before release would be nice. But that's not how Linux works.  Linux
 > > does regression testing after release.
 > > 
 > And who says that couldn't change?
 > 
 > In my oppinion it would be nice if Linus/Andrew had some basic
 > regression tests they could run on kernels before releasing them.

The problem is that this wouldn't cover the more painful problems
such as hardware specific problems.

As Fedora kernel maintainer, I frequently get asked why peoples
sound cards stopped working when they did an update, or why
their system no longer boots, usually followed by a
"wasnt this update tested before it was released?"

The bulk of all the regressions I see reported every time
I put out a kernel update rpm that rebases to a newer
upstream release are in drivers. Those just aren't going
to be caught by folks that don't have the hardware.

The only way to cover as many combinations of hardware
out there is by releasing test kernels. (Updates-testing
repository for Fedora users, or -rc kernels in Linus' case).
If users won't/don't test those 'test' releases, we're
going to regress when the final release happens, there's
no two ways about it.

		Dave


  parent reply	other threads:[~2005-07-15  2:11 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
2005-07-15  2:09     ` Dave Jones [this message]
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=20050715020912.GB22284@redhat.com \
    --to=davej@redhat.com \
    --cc=ak@suse.de \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@linux.intel.com \
    /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