linux-kernel - Re: mainline build failure due to cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wjypw2PL-w5ZBxY97SgRWd21f2V2Cuyw-ebsiTpSNQjBg@mail.gmail.com>
Date:   Thu, 18 May 2023 13:44:35 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nicolas Dufresne <nicolas@...fresne.ca>
Cc:     Linux regressions mailing list <regressions@...ts.linux.dev>,
        "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@...il.com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        NXP Linux Team <linux-imx@....com>,
        linux-media@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>
Subject: Re: mainline build failure due to cf21f328fcaf ("media: nxp: Add
 i.MX8 ISI driver")

On Thu, May 18, 2023 at 12:53 PM Nicolas Dufresne <nicolas@...fresne.ca> wrote:
>
> I'm expected to be flamed for getting in the way, but whatever. To me this
> decision lacks any kind of consideration toward who will be affected. This will
> hit those that makes the new features and are working hard to convince their
> customers to go mainline first.

I think the solution may be for those affected people to help Mauro & co.

Clearly the media maintenance doesn't have enough time. I'm not going
to pull from a tree where I know that it then may take six *weeks* and
one whole release for simple bugs to be fixed.

That is literally what happened. And if it had been once, that would
be one thing. But when the same thing starts happening again the very
next release, it's no longer a one-off. It's a pattern.

> Punishment and shame is not something I encourage or think is nice in general.

This is NOT about punishment.,

It's very simple: if I cannot trust the tree to be maintained, I'm not
going to pull it.

That's not punishment, that is simply about kernel maintenance.

If you want to help fix the media maintenance issue, then by all means
help. But as things are now, if I cannot rely on the media tree
getting even simple build fixes in a timely manner, then I'm not
pulling it.

Please realize: to misquote Shakespeare, I have two options: to pull
or not to pull. And in order to pull a tree, I need to know that I can
expect any problems from that pull to be fixed.

Would you expect me to pull known-buggy trees? I sure hope you don't
expect that. Not pulling buggy trees isn't "punishment". It's the only
sane thing to do.

And the exact same thing is true when a tree isn't maintained
properly. Bugs happen. That's inevitable. And sometimes bugs can be
hard to find, or hard to fix. But when the maintainer has been sent a
fix, and that fix doesn't get handled for SIX WEEKS, then that tree is
buggy.

Something is very rotten in the state of media. It needs to get fixed.
Until it is fixed, I don't want to take random new code.

The fix *may* be as simple as more testing, and better automation. But
really, the thing that annoyed me enormously was that these bugs were
all found by automation and testing. And still they were left to rot.

                 Linus