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