MIME-Version: 1.0
References: <C8C4DFDA-998F-48AD-93C9-DE16F8080A02@meta.com>
 <CAHk-=wghhViNZCj4ibSr42HjVGdHro_DWW7wCOQ61p2v59cciw@mail.gmail.com>
 <4BA6A759-F69C-406E-9D29-EDCC9B48F798@meta.com> <CAHk-=wjCNtTJ3DrG1266xXPZF=qH=GvpWApkYStJ9knskRnU3w@mail.gmail.com>
 <2B90FACE-74EB-47C8-91FD-62E3F77B95EC@meta.com>
In-Reply-To: <2B90FACE-74EB-47C8-91FD-62E3F77B95EC@meta.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 3 Mar 2023 10:16:37 -0800
Message-ID: <CAHk-=wj9xdS8hR1NWC8ZuvR2M35kHe9Tz5ERr5m9B=BUaPNv0Q@mail.gmail.com>
Subject: Re: [GIT PULL] zstd changes for v6.3-rc1
To:     Nick Terrell <terrelln@meta.com>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Nick Terrell <nickrterrell@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Mar 3, 2023 at 10:03=E2=80=AFAM Nick Terrell <terrelln@meta.com> wr=
ote:
>
> What do you prefer I do with my current tree? I guess I can either:
> - Leave the merges in and keep a stable tree
> - Fix up my tree and clean up the merges, but break the stable tree

In this case, since I'm not taking it during the merge window anyway,
just reset and rebase and basically start a new fixes branch that can
get pulled next week after it's been in that form in linux-next.

All of the actual real commits (ie the non-merge ones) seem to be
fixes, so let's just treat them as such.

And for sanity reasons, don't start the branch at a "random commit of
the day". Particularly not during the merge window. You want the
starting point to be something that doesn't have random issues that we
may not even know about yet - simply because you want *your* branch to
be as stable as possible, and you should aim to have to worry about
issues with zstd, not some random "oops, that particular base had a
random bug because of some merge window thing that wasn't found until
-rc3".

So start the fixes branch at a reasonable stableish point (in this
case presumably just 6.2).

Of course, the same thing is true of new development branches too, not
just fixes branches.

It's a bad idea to build a house on quick-sand, and it's a bad idea to
start new development on some unstable source base.

(One special case of "start development at a stable point" is to
simply continue off some old point of your previous development. Then
it's stable not because it was some known release, but simply because
it's what you used previously and had no issues with).

That whole "pick a stable point" thing is worth noting also for the
case when you _do_ decide that yes, you do need to rebase or
back-merge, and you have a good reason to do so. Don't merge a random
commit of the day. Merge a _specific_ commit that you can explain why
you picked _that_ point to merge.

Of course, things like tagged releases aren't necessarily stable by
definition - we find things to fix after release too. But at least
they are hopefully "we at least tried to make sure it wasn't a bad
point".

              Linus