[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wioGrBpYXENm73w0OHvzhFtETgkaUH+5LYovRWOHJpZ0A@mail.gmail.com>
Date: Tue, 16 Jul 2024 13:43:32 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <kees@...nel.org>
Cc: linux-kernel@...r.kernel.org, Jeff Johnson <quic_jjohnson@...cinc.com>,
Justin Stitt <justinstitt@...gle.com>, Kees Cook <keescook@...omium.org>,
linux-hardening@...r.kernel.org
Subject: Re: [GIT PULL] pstore updates for v6.11-rc1
On Mon, 15 Jul 2024 at 09:29, Kees Cook <kees@...nel.org> wrote:
>
> Please pull these small pstore updates for v6.11-rc1. (Note that since there
> were no pstore updates for v6.10, this is based on v6.9-rc2. I forgot
> to do my traditional merge-on-rc2 for this tree when v6.10-rc2 happened.)
Note that this is exactly what should happen. No need to do any
back-merges if some sub-area has been quiet.
Sure, if some branch is *really* old, you might want to do a
test-merge just to see if there are conflicts (either textual or just
due to infrastructure changes elsewhere that cause old changes to not
work in a modern context), but honestly, even that is just a "nice to
have".
But "missed one release" is not very old in the big picture. We do
releases relatively often, after all.
So then merge conflicts like that are on me as a top-level maintainer,
and if they end up being very complex I might come back to you and ask
for guidance. But honestly, that's quite rare.
IOW, I'd much rather developers concentrate on their own branch and on
making it very solid, rather than worry too much about what has
happened elsewhere meantime.
(Of course, that's all for the simple and good case where you have
clearly separate trees - which pstore largely is. Some other areas get
a lot more "this is affected by other changes and in turn affects
other areas", and then people there have to inevitably be more
involved with what has been going on).
Linus
Powered by blists - more mailing lists