linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Huacai Chen <chenhuacai@kernel.org>
Cc: "Regzbot (on behalf of Thorsten Leemhuis)" 
	<regressions@leemhuis.info>,
	Javier Martinez Canillas <javierm@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux regressions mailing list <regressions@lists.linux.dev>
Subject: Re: Linux regressions report for mainline [2023-10-29]
Date: Sun, 29 Oct 2023 16:52:42 -1000	[thread overview]
Message-ID: <CAHk-=wiX0j=8DB0EbCheAAfcx2z99QUZMTeJUxSBGpb0J5pjVg@mail.gmail.com> (raw)
In-Reply-To: <CAAhV-H4DXYm+nEV8zrfMMPvqstHV+FsQaFB8s1_rNu_ENC-q7g@mail.gmail.com>

On Sun, 29 Oct 2023 at 16:18, Huacai Chen <chenhuacai@kernel.org> wrote:
>
> We are investigating and hope the simpledrm problem can be fixed in
> some days [1],

I don't understand your "some days".  The original report was two+
weeks ago, and the link you point to does not seem to have a suggested
patch for the problem either.

So where does the "some days" come from?

The WHOLE POINT of the "no regressions" rule - and the reason it came
to be in the first place - was that we used to have these endless "one
step forward, two steps back" things with suspend/resume in
particular, where people fixed one device, but then broke a random
number of other devices, and kept saying " but I fixed something".

No. If you broke something else, YOU DIDN'T FIX ANYTHING AT ALL.

This is literally why we have that "no regressions" rule. No amount of
"but it's a fix" is valid at all if something else breaks. And no
amount of "I will fix the thing I broke in the future"  is valid
either.

If you don't have a fix for it, it's broken. And I don't even see a
*suggested* fix for people to try out.

> and the blank screen seems not a very harmful problem
> (maybe I'm wrong but I think most of people are using GUI now). So,
> can we keep the commit 60aebc9559492c at this time?

At least the email from Evan Preston seems to imply it's a blank
screen that doesn't go away.

  "Upgrading from Linux 6.4.12 to 6.5 and later results in only a
blank screen after boot and a rapidly flashing device-access-status
indicator"

And no, "most people using GUI" doesn't matter. You are supposed to be
able to upgrade your working kernel, and it's supposed to keep
working. That's *important*, because it's really really important that
people *trust* that they can upgrade the kernel and not end up with
something non-working, because that's how people then dare do kernel
updates and dare test new kernels.

If people then stop testing new kernels because they think new kernels
might break their setup, we have lost something truly important.

And yes, there are always exceptions. At some point, devices are just
too old legacy and there is no way of testing. Or we've had some
interface that was *so* mis-designed that it was a fundamental
security issue or something like that.

But no, this does not seem to be one of those issues.

Now, I'm not going to revert it just before releasing v6.6 (which I
have locally tagged, but not pushed out yet). And I'll have the merge
window for 6.7 opening tomorrow. But if this is not fixed by -rc1,
we'll just revert it.

                    Linus

  reply	other threads:[~2023-10-30  2:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-29 13:52 Linux regressions report for mainline [2023-10-29] Regzbot (on behalf of Thorsten Leemhuis)
2023-10-29 17:19 ` Linus Torvalds
2023-10-30  2:18   ` Huacai Chen
2023-10-30  2:52     ` Linus Torvalds [this message]
2023-10-30  3:10       ` Huacai Chen
2023-10-30 15:49   ` Thorsten Leemhuis

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='CAHk-=wiX0j=8DB0EbCheAAfcx2z99QUZMTeJUxSBGpb0J5pjVg@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=javierm@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=regressions@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    /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).