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

#regressions

1 post1 participant0 posts today

The two [1] recently affecting many people in mainline and various stable/longterm series should soon be a thing of the past:

Linus merged fixes into 6.12-rc4[2] and Greg queued them for the next stable releases[3].

Wondering what we should learn from this wrt to handling such regressions quickly and ideally even preventing them from hitting stable.

[1] lore.kernel.org/all/4e1977ca-6

[2] git.kernel.org/torvalds/c/d7f5

[3] lore.kernel.org/all/2024102100

Can you come up with convincing *stats* on why backporting a huge pile of patches (say 800+, like in the case of 6.10.3) to stable series just days after being mainlined *during the merge window* and thus included in a mainline -rc1 is *worse* than quickly backporting changes mainlined *during the rest of the development cycle*?

Then tell me about it, because then I'll bring this up on the maintainers summit while talking about .

1/ FWIW, this is what I tried: I…

Continued thread

2/ Also note that Linus' message[1] indirectly explains why you might not be able to claim "no regressions" when you only find a problem after updating from one longterm aka LTS series to a later one:

By then others might have started relying on the new behaviour, hence fixing the regression might be impossible without causing a regression for those other people – and then you might lose out.

[1] lore.kernel.org/all/CAHk-=wgtb

Ever wondered why @torvalds coined the 's "no regressions" rule? He just explained it again here: lore.kernel.org/all/CAHk-=wgtb

'"[…] I introduced that "no regressions" rule something like two decades ago, because people need to be able to update their kernel without fear of something they relied on suddenly stopping to work. […]"'

Follow the link for context and other statements that did not fit into a toot.

I might regret this later, but... What are the pros and cons of five-point vs. seven-point #Likert scales, and what are the risks of changing from whatever a measure was developed for? I've seen opinionated blog posts on this, but is there actual #research on this, or #simulations or the like? We're working on a #survey, data will be used for multivariate #analysis like #regressions, #SEM and the like. On one hand, we'd like to preserve the scale options the different included measures were developed for. On the other, we want to standardize response options across the survey.

one of today's lessons is that if each FOSS package had their own test suite for performance regressions one might catch an odd spike in CPU/latency/memory/network that is a symptom of a backdoor or attack attempt. if its new AND unexpected one should dig in

I'm the author of a FOSS Golang latency instrumentation lib designed especially to be used by perf regression tests:
github.com/mkramlich/LatLearn

#cve20243094
#xz
#lzma
#liblzma
#backdoor
#openssh

#Golang
#latency
#performance
#Regressions

GitHubGitHub - mkramlich/latlearn: latency instrumentation and reporting lib for Golanglatency instrumentation and reporting lib for Golang - mkramlich/latlearn

Really glad that @gregkh refuses[1] to pick up changes for stable/longterm series (say 5.4.y), if they have not yet been applied to all newer series (e.g. 5.10.y, 5.15.y, …). This is crucial, as people otherwise would run into if they'd sooner or later update from the older to one of the newer series.

[1] every few weeks (or even more often) some developer learns that aspect through a mail like lore.kernel.org/all/2024022603

lore.kernel.orgRe: [PATCH v2 0/7] 5.4 backport of recent mds improvement patches - Greg KH
Continued thread

- No way to fine tune pressure curve of the tablet, various people draw with varying pressure some people draw with heavy hand some use light touch, configuring pressure curve helps artist to get nice lines. - bug report -

bugs.kde.org/show_bug.cgi?id=4

🧵 7

bugs.kde.org477671 – Feature to save and restore different tablet configuration profiles and change them with a shortcut
Continued thread

Graphic tablet support bugs

- No way to map a portion of the tablet are to the screen - Some people have large tablet and sometime they want to map a portion of the tablet to the

bugs.kde.org/show_bug.cgi?id=4.

Moreover the UI for mapping tablet area and its buttons is slightly inferior to the UI of the same functionality in X11 KCM. - Bug report - bugs.kde.org/show_bug.cgi?id=4

🧵 5

bugs.kde.org457703 – Feature to to map an area on the tablet surface to the entire screen