linux-kernel - Re: [GIT PULL] zstd changes for v6.3-rc1

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Mar 2023 09:59:07 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nick Terrell <terrelln@...a.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nick Terrell <nickrterrell@...il.com>
Subject: Re: [GIT PULL] zstd changes for v6.3-rc1

On Fri, Mar 3, 2023 at 9:54 AM Nick Terrell <terrelln@...a.com> wrote:
>
> I’m sorry, I thought this was standard practice for merging in the mainline branch.

Absolutely NOT.

I have harped on "DO NOT DO BACK MERGES" for closer to two _decades_ by now.

When you do zstd development, you should normally have absolutely
*ZERO* reason to merge non-zstd work.

> I’ve been following this article [0], which recommended not rebasing my public
> trees, so I merged in the mainline kernel instead.

Half right.

You should not rebase your public trees.

But you should not merge mainline either.

Exactly what relevance does <N> *thousand* driver updates have to zstd?

There are reasons to merge, but they have to be real, explicit, and
MENTIONED IN THE MERGE.

And no, "update to latest" is simply not a reason.

When close to half the commits are pointless merges that have no
explanation, I will not pull (if I notice).

                 Linus