linux-edac.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-edac <linux-edac@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] EDAC updates for v6.4
Date: Tue, 25 Apr 2023 09:55:14 -0700	[thread overview]
Message-ID: <CAHk-=wgrN-uPnNTamBwrxMgibBH9N9zX57nbDW7_hLdi4SstQw@mail.gmail.com> (raw)
In-Reply-To: <20230424072836.GAZEYvpDGrV3bXx690@fat_crate.local>

On Mon, Apr 24, 2023 at 12:28 AM Borislav Petkov <bp@alien8.de> wrote:
>
> For some stupid reason (juggling gazillion things at the same time,
> probably) I have based the edac-amd64 branch *not* ontop of plain
> v6.3-rc3 but there are a couple more of your merges ontop.

It's fine. Mistakes happen, and honestly, the "base your work on top
of a stable point" is - like almost everything else in life - a
recommendation for everybody's sanity, rather than any kind of
black-and-white rule.

And it comes mainly from people actively mis-using git, and merging
random upstream state without thought, and trying to set that kind of
behavior right, and have people _think_ about it.

IOW, it's not some "this gets enforced" thing - it's more of a "you
did something else horribly wrong, so let's clarify what the 'good
thoughtful git behavior' should be".

Sometimes starting at a random point can even be a feature - random
cleanups that depend on some helper that was added last release, and
it's just much more convenient to start at point X ratherr than wait
for the next -rc.

Now, the thing I do hope that people actively try to avoid is picking
a "kernel of the day" during the merge window to start on, but even
that is less about "well-defined starting point" and more about just
the fact that the merge window kernel *can* be really unstable and is
a really bad base.

But some "rc3+" kernel is certainly not that kind of _horribly_ bad
kernel to start at. It's probably better than starting at a rc1
release in practice.

So the "try to use a reasonably stable starting point" really is a
general recommendation, and mostly a reaction against people who tend
to do more of a mindless "rebase/merge to today's kernels without any
thought" kind of workflow.

So I'm not asking for surgical precision. I'm asking for "reasonable
workflow", where people avoid doing pointlessly silly things.

                 Linus

  reply	other threads:[~2023-04-25 16:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-24  7:28 [GIT PULL] EDAC updates for v6.4 Borislav Petkov
2023-04-25 16:55 ` Linus Torvalds [this message]
2023-04-25 17:35   ` Borislav Petkov
2023-04-25 17:47     ` Linus Torvalds
2023-04-25 18:00 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=wgrN-uPnNTamBwrxMgibBH9N9zX57nbDW7_hLdi4SstQw@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).