Messages in this thread | | | From | Nick Terrell <> | Subject | Re: [GIT PULL] zstd changes for v6.3-rc1 | Date | Fri, 3 Mar 2023 18:26:05 +0000 |
| |
> On Mar 3, 2023, at 10:16 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Fri, Mar 3, 2023 at 10:03 AM Nick Terrell <terrelln@meta.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
| |