Re: [GIT PULL] zstd changes for v6.3-rc1

[Nick Terrell]

> On Mar 3, 2023, at 10:16 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> On Fri, Mar 3, 2023 at 10:03 AM Nick Terrell <terrelln@xxxxxxxx> wrote:
>> 
>> 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.

I will go ahead and do that.

> 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".

Thanks for the time you’ve taken helping me. I will also take some
more time to better familiarize myself with the maintainer workflow, so I
can avoid other mistakes that I don’t know I’m making.

Best,
Nick Terrell

>              Linus