Login

Recent searches

No recent searches

Search options

Only available when logged in.
fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

10K
active users

fosstodon.org: AboutStatusProfiles directoryPrivacy policy

Mastodon: AboutGet the appKeyboard shortcutsView source codev4.3.7

Public
Thorsten Leemhuis (acct. 1/4)

regressions only reported after a long time[1] will be handled as bugs (IOW: the "no regressions" rule does not really apply any more), as this recent mail from Linus shows:

lore.kernel.org/all/CAHk-%3Dwg

[1] How long? Not sure, in the end that's up to Linus. But from an earlier mail of him I guess it everything found after more that a year might become problematic:

lore.kernel.org/all/CAHk-=wis_

Public
Krzysztof Kozlowski
@kernellogger Linus expressed few times that if something was broken for very long time, was not working for long time, it should not be treated as urgent/important fix thus should not go to current RC cycle. Instead, should go via normal development branch, so for the next merge window. I know that stable folks have different point of view - they also expressed it.

I personally follow exactly the same approach in handling fixes: if something was broken for long time, it is regular bugfix thus goes to "for-next" branch, not "fixes / for-linus / for-current-rc".

Now, if a regression was unnoticed for 8 years, it kinda fits above criteria.
Public
Thorsten Leemhuis (acct. 1/4)

@krzk

yeah, I'm aware of it; but I think I'd classify them in three different categories:

* recent regressions (~past year): devs are obliged to fix, ideally through fixes/for-linus/for-current-rc

* older regression (~one to two or three years?): devs are obliged to fix, ideally in the next merge window if timing permits

* anything older: treat it like any other bug

Public *
Thorsten Leemhuis (acct. 1/4)

@krzk

and wrt. to stable:

the "# after X weeks in mainline" (X=4 or 6 or something) option could reduce the pain[1], but that is bound to the stable tag; and we lack a "nostable" tag, too[2]. 🥴

[1] docs.kernel.org/process/stable

[EDIT]
[2] maybe we could introduce

Cc: <stable@vger.kernel.org>

or something like that to make "do not backport" obvious

[/EDIT]

docs.kernel.orgEverything you ever wanted to know about Linux -stable releases — The Linux Kernel documentation
Public
Krzysztof Kozlowski
@kernellogger Oh, interesting, I did not know about the "delay" argument. The no-stable is so far a bit per subsystem. Some of them, like I think netdev, rely on marking things explicitly cc-stable. Most don't care thus anything with Fixes tag is picked up.
ExploreLive feeds
About