Notices by Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org), page 2

2/ Ohh, and if you haven't seen this related post from @monsieuricon, you might want to go and check it out, too:

https://social.kernel.org/objects/860ef93c-229b-4070-8ee6-cb80d1f51337

'"[…] I'm not a lawyer and I don't speak for the LF, so I won't give you any kind of "official comment." But here's my view of it.

The people removed from maintainer positions were identified as employed by companies on the US and EU sanctions list. These companies are directly involved in the Russian military complex and therefore […]"'

2/ @kees replied to the "linus-next" proposal from Sasha and raised a few points I fully agree with, as that proposal felt a bit off for me.

https://lore.kernel.org/all/792F4759-EA33-48B8-9AD0-FA14FA69E86E@kernel.org/

"'Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem.

[…]

Why not just use linux-next? […]

[…] have a bot that replies to all PRs with a health check, and Linus can pull it if he thinks it looks good. […]"

#Linux #kernel #LinuxKernel

linus-next: improving functional testing for to-be-merged [#linux #kernel] pull requests

https://lore.kernel.org/all/ZxZ8MStt4e8JXeJb@sashalap/

"'[…] Linus Torvalds expressed concerns about the quality of testing that code receives before he pulls it. The subsequent discussion side-tracked to the testability of linux-next, but we didn't directly address Linus's original concern about pre-pull testing quality.

In an attempt to address the concerns, we're trying out a new "linus-next"
tree […]"

#LinuxKernel

@ljs @kees @vbabka

Well, good points, but fwiw, afaiui only patches that *were* reviewed by one of the official maintainers are supposed to be included in -next. To quote Stephen from https://lore.kernel.org/linux-next/20240716083116.27f179bd@canb.auug.org.au/

"'You will need to ensure that the patches/commits in your tree/series have
been:
[…]
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window."'

@vbabka and @ljs, that "Are people putting things in linux-next that they don't expect to send to Linus? That seems like the greater problem." from @kees reminded me of a question you might be able to help out with:

From a quick look it seems to me that the "mm-unstable" branch is in -next (via "mm-everything"). Does that contain stuff for the next merge window only, or more experimental stuff as well? It looks like the latter to me.

@ljs @kees @vbabka

eating data is always a risk spectrum (even in stable release there is a risk that it happens) -- and depending on how risky something looks people then decide what they use/test: stable, stable-rc, mainline outside the merge window (that's me currently), mainline all the time, -next.

The less likely the "might eat data" risk is perceived in -next, the more likely people will be willing to help with testing it.

@ljs @kees @vbabka

> I think the issue is that more people need to test against -next.

Avoiding "this might eat my data" fears for the testers is very important detail here to realize that – having patches in there that come from a "unstable" branch is enough to scare people away when it comes to mm or filesystems.

So chancing that name might already help.

@vbabka @kees @ljs

yeah, sounds like it; and bots could even process that mm-experimental branch, like they do for quite a few other subsystem trees not included in -next.

@Suiseiseki

I don't think GNU/Linux et. al. make much sense, as these things change; but I think */Linux_(kernel), */Linux_(operating system) (which then refers for */Linux_(Distributions)[1], */Android, */ChromeOS, …) would make a whole lot of sense.

[1] for Debian, Fedora, Ubuntu. et. al. – I don't like that name much, but I'm optimistic something better could be found with some head scratching…

@Suiseiseki

you and I might not like it, but for a lot of people Linux is not a kernel, but a operating system.

Not a problem per se, but I hope that at least wikipedia one day will learn this and make
https://en.wikipedia.org/wiki/Linux a landing page that leads to two different pages (one for the OS, one for the kernel).

@ptesarik @Aissen @mpe

> Thorsten, we're all hanging on your lips, ready to make patches like crazy!

Be careful what you say, otherwise I might follow your advice. 😬 🙃

I was tempted a few hours ago -- but quickly decided submitting a rough patch myself is the way better approach. 😄

See https://lore.kernel.org/all/42aa307d7ffae1851b4a8787f5c276dd0b3beece.1728543368.git.linux@leemhuis.info/ or https://fosstodon.org/@kernellogger/113281883813298472 for details.

Seems I need to be more careful what I write here, as it seems one of my sneaky remarks lead to a #Linux #Kernel patch. 😂

powerpc/boot: Remove bogus reference to #lilo – https://lore.kernel.org/all/20241009053806.135807-1-mpe@ellerman.id.au/

From @mpe – and according to the Link tag triggered by https://fosstodon.org/@kernellogger/113032940928131612 (see Screenshot)

#LinuxKernel

The #Linux 6.12 pull request for #PREEMPT_RT is handed to Linus. Likely the first PR ever submitted in printed form. #kernel #LinuxKernel #Realtime

@ljs @lkundrak

😂

Coke: yeah; might even drink a glass/cup or two per year at a party or the cinema

Club mate: maybe two or three times.

I grew up on sugared drinks and decided that those where round about enough for one lifetime…

/me fears this answer will make matters worse 😬

@ljs @lkundrak

from the "make matters worse department"😂:

I grew up an area where they drink a lot of tea and stuck to it; I drink maybe one coffee every two month.

https://www.unesco.de/en/east-frisian-tea-culture

There is something worse, but I'll tell you next week in person. 😬

2/ Side note:

* the list of TAB members on on https://www.linuxfoundation.org/about/leadership is out of date afaics.

* Where is the current landing page that lists what the TAB actually does? https://wiki.linuxfoundation.org/tab/start seems old, but might be it.

Is there anything you would like to ask the #Linux Foundation's TAB (Technical Advisory Board)?

Then come to the "ask us anything" session with the current TAB at the @linuxplumbersconf 2024, which is currently scheduled for 9:00 on Friday, September 20[1].

And if you can't be there, just tell me your questions: I'll try to bring a few of them forward if I get a chance.

[1] https://lore.kernel.org/all/87zforv3zc.fsf@trenco.lwn.net/

#kernel #LinuxKernel #LinuxPlumbers #LinuxPlumbers2024

@ljs

never heard of it, not sure if that was ever sold in Germany; but even if it was, I most likely would not be aware of it, because I'm boring and avoid drinks like that most of the time…

#Linux #kernel patches to allow enabling #PREEMPT_RT (aka proper #realtime support) for x86, ARM64, and Risc-V were posted for review:

https://lore.kernel.org/lkml/20240906111841.562402-1-bigeasy@linutronix.de/

"The printk bits required for PREEMPT_RT are sitting in linux-next. This was the last known roadblock for PREEMPT_RT. The RT queue has additionally the "atomic console" for the 8250 UART which is not yet in linux-next.[…]"

See also these earlier other related toots:

https://fosstodon.org/@kernellogger/113084762433941141
https://fosstodon.org/@kernellogger/113085326251565367

Support for QR code #kernel panic screens[1] is now in #Linux-next[2] and thus slated for inclusion in #LinuxKernel 6.12. 🥳

Note, the QR encoder requires #Rust / #Rustlang support to be enabled when building the kernel, as it is written in Rust (see [2]).

[1] for details, see this patch series: https://lore.kernel.org/all/20240822073852.562286-1-jfalempe@redhat.com/

[2] see among others https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cb5164ac43d0fc37ac6b45cabbc4d244068289ef