linux-kernel - Re: [GIT PULL] EDAC updates for v6.4

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-=wiNnK--B_K7DHvU28PKX00fUpb9oUmSq9OpkOLPDrMkUQ@mail.gmail.com>
Date:   Tue, 25 Apr 2023 10:47:50 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-edac <linux-edac@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] EDAC updates for v6.4

On Tue, Apr 25, 2023 at 10:35 AM Borislav Petkov <bp@...en8.de> wrote:
>
> While we're on the topic: when we send you tip urgent fixes, we base
> each branch off of the current -rc, put the urgent fixes ontop, test,
> ... and send them to you in a week's time, roughly.
>
> Now, after you've pulled, we could fast-forward the urgent branch to the
> next -rc where new fixes come - and I do that most of the time - or we
> could not do that because of, as you say, if there's no really good
> reason to fast-forward (important other fix, new functionality from the
> newest -rc a patch needs, yadda yadda) then those urgent branches do not
> necessarily have to be fast-forwarded but simply get more fixes applied
> ontop.

That sounds right. Do the fast-forward thing if you want to update to
a newer rc for some other reason, but if there's no major other thing
going on, you can easily just continue on top of your existing fixes
branch.

There's no reason to actively seek a new base if you already had a
stable base that you were on.

So whatever works best for you.

(Of course, at some point "that base is just _really_ old" becomes a
reason in itself, and then fast-forwarding to have a newer base to do
your fixes on top just becomes a convenience)

> Oh, and I'm sure if a branch is based on what looks like a random point
> but there's a good explanation accompanying it why it is based on that
> random point, then I guess that's perfectly fine too.

Absolutely. Things that look wrong when I look at the pull request
result may have good reasons for them. If you know there's something
odd going on but you had a particular reason to do it that way, just
mention it.

For example - I can get quite upset when I see that all the commits
are very recent and have clearly not had a lot of testing. But if that
isn't your usual pattern, and you had a clear *reason* for the commits
all being shiny and new ("I had to rebase to remove a completely
broken commit"), please mention it.

Of course, if that particular reason keeps on happening, and there' sa
continual stream of "I know I did things wrong, but it was because of
X", then maybe that "X" is a huge problem and should be fixed?

So the occasional oddity with explanations is perfectly fine. But a
consistent _pattern_ of oddities is a problem, explanations
notwithstanding.

              Linus