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

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]

Date:   Fri, 3 Mar 2023 18:26:05 +0000
From:   Nick Terrell <terrelln@...a.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
CC:     Nick Terrell <terrelln@...a.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nick Terrell <nickrterrell@...il.com>
Subject: Re: [GIT PULL] zstd changes for v6.3-rc1


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