intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	Keith Packard <keithp@keithp.com>
Cc: Pekka Enberg <penberg@kernel.org>,
	intel-gfx@lists.freedesktop.org, Tomas Winkler <tomasw@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Disable all outputs early, before KMS takeover
Date: Tue, 5 Apr 2011 07:42:14 -0700	[thread overview]
Message-ID: <BANLkTinXZVOy9-j4TiJ7HMcTvv9Q8RS+DA@mail.gmail.com> (raw)
In-Reply-To: <b7da2f$qvoau5@fmsmga001.fm.intel.com>

On Tue, Apr 5, 2011 at 3:30 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> On Tue, 5 Apr 2011 13:21:08 +0300, Tomas Winkler <tomasw@gmail.com> wrote:
>> On Fri, Apr 1, 2011 at 2:51 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> > Unfortunately I get a blank screen with after boot:
>> > Nacked-by: Pekka Enberg <penberg@kernel.org>
>
> But until you can tell me where it explodes on your system, we fix
> issues on several other machines...

NO.

Chris, you need to understand the issue of "NO REGRESSIONS".

It's a very simple rule: it DOES NOT MATTER ONE WHIT how many machines
you fix. You never ever regress. Patches that cause regressions are
reverted.

There are multiple reasons for that rule, but the basic one ends up
being very simple: you only _think_ you fix more machines than you
break. Why? Because the people who test out your patches are the
"active" people - and often predominantly the active people who have
problems. In contrast, the people for whom things already work aren't
even testing your patches in the first place. Then, six months later,
when they update to a new Fedora version, things suddenly don't work
for them, and it turns out that yes, you fixed ten active testers, but
you broke a thousand random people.

So even _one_ person saying "this is a regression" is a total blocker.
Really. It's that simple.

YOU NEVER EVER BREAK WORKING MACHINES.

Seriously. We had this for years in ACPI-land and with suspend/resume
with "one step forward, two steps back", and nobody ever knew if we
were doing any real progress at all, because machines that had working
suspend/resume one kernel version would be broken again the next.
There was no real pattern of improvement, there was just a random
pattern of "things get fixed on one machine, and break on another".

We introduced the "no regressions" rule, and things got seriously
better. Suddenly things started getting _reliably_ better.

The whole situation with i915 has been pretty damn random lately, and
you really really need to understand that this is simply not how it's
done. Your cavalier attitude ("but it fixes things for others") is
absolutely not acceptable.

Keith Cc'd, because that patch had better not show up in my tree.

                       Linus

  parent reply	other threads:[~2011-04-05 14:42 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <AANLkTi=VqkYjdiDLJvM-OfmBSGx-EkRkt=4XCDEnvZsU@mail.gmail.com>
2011-03-29 10:46 ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Chris Wilson
2011-03-29 12:23   ` [PATCH] drm/i915: Move the irq wait queue initialisation into the ring init Chris Wilson
2011-03-29 13:05     ` Pekka Enberg
2011-03-29 13:22       ` Chris Wilson
2011-03-29 13:39         ` Pekka Enberg
2011-03-29 14:22           ` Pekka Enberg
2011-03-29 14:32             ` Chris Wilson
2011-03-29 15:21               ` Pekka Enberg
2011-04-01 11:44   ` [PATCH] drm/i915: Disable all outputs early, before KMS takeover Daniel Vetter
2011-04-01 11:51     ` [Intel-gfx] " Pekka Enberg
2011-04-05 10:21       ` Tomas Winkler
2011-04-05 10:30         ` Chris Wilson
2011-04-05 10:37           ` Pekka Enberg
2011-04-05 11:55             ` Tomas Winkler
2011-04-05 14:11             ` Pekka Enberg
2011-04-05 14:27               ` Chris Wilson
2011-04-05 14:31                 ` [Intel-gfx] " Pekka Enberg
2011-04-05 14:34               ` Chris Wilson
2011-04-05 15:11                 ` Pekka Enberg
2011-04-05 15:32                   ` Chris Wilson
2011-04-05 15:44                     ` Pekka Enberg
2011-04-05 14:42           ` Linus Torvalds [this message]
2011-04-05 15:01             ` Keith Packard
2011-04-05 15:12             ` [Intel-gfx] " Chris Wilson
2011-04-05 15:35               ` Pekka Enberg

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=BANLkTinXZVOy9-j4TiJ7HMcTvv9Q8RS+DA@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=keithp@keithp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penberg@kernel.org \
    --cc=tomasw@gmail.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;
as well as URLs for NNTP newsgroup(s).