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)

I fully understand why mainline developers do not have to care about stable maintenance (IOW: backporting to earlier, still supported series) at all.

And I'm mostly fine with it. But I think it's wrong when it comes to recent mainline regressions that bother users.

Especially when they cause severe damage like disk corruption (as seen by multiple reporters), as it this case:

lore.kernel.org/all/2024100316

Backstory: bugzilla.kernel.org/show_bug.c & lore.kernel.org/all/90f6ee64-d

#LinuxKernel
Public
Jens Axboe

@kernellogger IMHO maintainers very much need to (and should) care about stable! It's what people run, they don't run your development tree or the pristine new release from Linus. It's what distros rely on. Maintainers saying they don't care about stable is lazy and irresponsible.

Quiet public
Oleksandr Natalenko, MSE :verified:

@axboe @kernellogger I run Linus releases only exactly because I'm fed up with the "stable" stability.

Quiet public
Jens Axboe

@oleksandr @kernellogger probably these two problems go hand in hand. If maintainers took better care of stable, this would not be an issue.

Quiet public
vbabka
@axboe @oleksandr @kernellogger only if that means also opting out of backporting commits without explicit Cc: stable, like mm does
Quiet public *
ljs
@vbabka @axboe @kernellogger @oleksandr yeah I think there's one maintainer in particular who's deciding how things go on this.

I think it's a little unfair/silly to imagine that enterprise distros are choosing to filter stable commits because of some conception that maintainers are just 'not paying enough attention' to it.

Stable's notorious for being anything but.

Having spent the last 3 days working flat out on fixing a regression as a non-maintainer let's say I can also sympathise with those maintainers who get fingers wagged at them for not somehow ensuring autosel is done right somehow.
Quiet public
ljs
@vbabka @axboe @kernellogger @oleksandr I'd say the fact I more or less dropped my whole life to try to fix the regressions tells you how seriously _I_ take stability.

Think it's a bit easy to dismiss this as 'oh well you don't care' or something, whereas it seems to me the opposite is true - clearly some stuff in stable isn't so stable, and some things are not so easy to ensure don't get included.

Not every maintainer is as nice as they seem or don't seem, and giving a shit levels vary I'm sure, but feels very lazy to just say 'oh yeah that's maintainers being crap'.

Yeah no, I think there's more to it than that tbh.
Quiet public *
Jens Axboe

@ljs @oleksandr @kernellogger @vbabka There's no one true way, and I definitely don't care if maintainers say "don't include us in stable!" if it means that they handle it themselves and send whatever needs to go into stable to stable. What I find problematic is autosel + maintainers ignoring it, and that's clearly an autosel issue. I think it does more good than harm, but it definitely picks up patches it should not because dependencies aren't understood.

Quiet public
ljs
@axboe @oleksandr @kernellogger @vbabka maybe the existence of autosel just points to a big process fail in general?
ExploreLive feeds
About