linux-kernel - Re: [GIT PULL] bcachefs fixes for 6.11-rc5

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]

Message-ID: <CAHk-=wjwn-YAJpSNo57+BB10fZjsG6OYuoL0XToaYwyz4fi1MA@mail.gmail.com>
Date: Sat, 24 Aug 2024 10:57:55 +0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.11-rc5

On Sat, 24 Aug 2024 at 10:48, Kent Overstreet <kent.overstreet@...ux.dev> wrote:
>
> Sure, which is why I'm not sending you anything here that isn't a fix
> for a real issue.

Kent, bugs happen.

The number of bugs that happen in "bug fixes" is in fact quite high.
You should see the stable tree discussions when people get heated
about the regressions introduced by fixes.

This is, for example, why stable has the rule of fixes being small
(which does get violated, but it is at least a goal: "It cannot be
bigger than 100 lines, with context"), because small fixes are easier
to think about and hopefully they have fewer problems of their own.

It's also why my "development happens before the merge window" rule exists.

If you have to do development to fix an old problem, it's for the next
merge window. Exactly because new bugs happen. We want _stability_.

The fixes after the merge window are supposed to be fixes for
regressions, not "oh, I noticed a long-standing problem, and now I'm
fixing that".

But obviously the same kind of logic as for stable trees apply: if
it's a small obvious fix that would be stable material *anyway*, then
there is no reason to wait for the next release and then just put it
in the stable pile.

So I do end up taking small fixes, because at that point it is indeed
a "it wouldn't help to wait" situation.

But your pull requests haven't been "small fixes". And I admit, I've
let it slide. You never saw the last pull request, when I sighed, did
a "git fetch", and went through every commit just to see. And then did
the pull for real.

This time I did the same. And came to the conclusion that no, this was
not a series of small fixes any more.

             Linus