On Thu, Apr 2, 2026 at 3:02 PM Linus Torvalds <[email protected]> wrote: > > On Thu, 2 Apr 2026 at 11:27, Alex Deucher <[email protected]> wrote: > > > > There are always new fixes. Worse case it ends up in 7.0.1. If it > > causes other regressions, then we end up introducing a new regression > > in rc7. > > This was a regression in rc1, that was reported several weeks ago. > Anything that gets reported that early in the release cycle is bound > to hit lots of people, because the number of people testing early rc > kernels is relatively small. > > So why pointlessly delay *known* regressions for fear of a potential new one? > > And why point out rc7, when dammit, this could have been fixed long > before and *not* be that late in the release? > > The bug was reported a month ago. The patch was posted ten days ago. > > It could have been in rc6 and gotten a bit more testing, but was > delayed for unknown reasons, and now the argument is that we should > avoid the testing in rc7 and just put it in a stable release instead? > > What's the advantage of releasing 7.0 with a known problem, and delay > any potential reports of whatever new regressions in 7.0.1 instead? > > What is the logic here? Really? > > As you say, there are always new fixes. But how exactly does that > change anything? > > The fact that there will be new fixes just means that delaying known > fixes will only result in all those fixes just piling up. > > Or worse yet, all those known *problems* piling up, where known > problems may then end up hiding even more problems that people don't > even see because they hit the first issue. > > So what is the point? Why are things delayed? > > The whole reason we have rc release candidates is (a) finding bugs and > (b) GETTING THEM FIXED BEFORE THE ACTUAL RELEASE. > > What did you think a "release candidate" was all about if that's not > your reading of the issue? > > And if fixes look too scary or uncertain, we *revert* the change that > caused a regression. We don't go "fixing it is too scary". > > And yes, we have more timely releases than pretty much any other > software project has, and that is partly exactly so that things don't > build up over time. > > We don't want new features to build up over time - long long ago we > had long release cycles that then dragged out even *more* because > there just was too many changes and they all had issues that needed > fixing. > > But we also don't want the known problems to build up over time. > > One of the points of of "release early, release often" is to find bugs > quickly - and then *fix* them quickly so that we can leave the issue > behind instead of letting it fester and cause longer-term issues. > > This "drag your feet because there will always be other fixes" makes > absolutely no sense to me, and it's not how we work. > > So honestly, there are exactly two choices: apply the fix, or just > revert the commit that caused the problem in the first place. > > Because no, "let's just have a known regression" is not how we roll.
My point was just that I wanted to wait for our testing cycle to complete before I pushed the fix. In the past I've pushed fixes near the end of a kernel cycle without waiting for the testing to complete which ended causing more problems than they fixed. The testing has completed and the patch is good. I'll send Dave and Simona a PR momentarily. Alex
