SoC maintainership in the Linux kernel (long time ago called arm-soc) is growing into a group of maintainers. Four new people joined @arnd for SoC: Alexandre Belloni, Linus Walleij and me (yay!) as co-maintainers, and @fustini as a reviewer:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2a578f3127ab9ef80114cef9b20a2b42a8ee77a

Arnd, previously the sole SoC maintainer, handled pull requests and patches from several other sub-maintainers for each SoC sub-architecture (e.g. Qualcomm, NXP) and other driver trees. The SoC tree was one of the busiest, if not the busiest, trees in kernel - visible on @lwn.net graph: https://lwn.net/Articles/981742/

With this change the load will hopefully spread.

TWIMC, the "Linus opposes Link: tags with links to the patch submission" is saga over, as Linus wrote:

""[…] I do think that at least if people use the different domain, I won't complain.

I'm still not convinced it's a great idea, but at least it means that the "this is the source of the commit" is clearly separate from the "this is actual background". […]""

https://lore.kernel.org/all/CAHk-%3Dwj5MATvT-FR8qNpXuuBGiJdjY1kRfhtzuyBSpTKR%2B%3DVtw@mail.gmail.com/

#Linux #kernel #LinuxKernel

Not only did a permanent member of the UN security council attack a clearly marked UN humanitarian convoy with FPV Drones, they also proceed to proudly share the footage of their appalling crime on the internet.

https://news.un.org/en/story/2025/10/1166099

@ptesarik @corbet OK, so answering more precisely your question from where does 100 come - from checkpatch. Sometimes people identify checkpatch as the coding style. But few maintainers expressed on mailing list preference of 100.

@ptesarik @corbet Coding style does not need update, it is vague on purpose, because sticking to hard limits is not necessarily good. That's why checkpatch has different limit - people treated its output too literally.
Now some maintainers PREFER 100. I don't know your case here - ask maintainer of that code, which might be that person nitpicking you :)

@conor @gregkh Conor, the last paragraph gives the answer :) http://www.kroah.com/log/blog/2025/10/01/the-only-benchmark-that-matters-is.../

@conor Ha! I got you into LWN :) https://lwn.net/Articles/1039531/

@conor I see now that the stalling-email from vendor partially worked and discouraged community from maintaining the code. Sigh...

@kernellogger @pojntfx @thomasmey yep, sending patch is the first step anyway, regardless of actual status in the maintainers file.

When a vendor wants to control upstreaming process and objects to community-led patches, I’ll just point to this brilliant response from @conor:

It’s only better if <vendor name> submits better quality patches (no evidence for that yet) or submits the patches more promptly than others (which clearly has not happened here), and offers review commentary etc at a higher standard and more frequently than a non-employee maintainer would be able to do (there’s no evidence for that so far either, given you’re trying to stall this patchset). Your claim seems to have no merit as there is no proof that you’d do a better job.

https://lore.kernel.org/all/20250925-jaundice-uneasy-ff8b3b595879@spud/

Collaboration and communication are at the heart of Linux kernel development. In the second part of our series, we explore how to work effectively with the Linux kernel community.

Read more here 👉 https://lnkd.in/eYgrqWZs

#Linaro #LinuxKernel #Tech #KernelDeveloper

@gregkh Oh, thanks for sharing! People received only cover letter and we all know how we treat cover letters, especially ones without patches :)

Work looks interesting, maybe it will solve the problem Bartosz and Wolfram were speaking about on conferences.

@brauner @monsieuricon @kernellogger @geert Please check the link to doc patch from @geert - different domain does not solve dislike for automated Link:, as it seems.

@geert @kernellogger @monsieuricon So I guess that's the answer to question if patch.msgid.link domain solves Linus' issue:
https://lore.kernel.org/all/497c9c10-3309-49b9-8d4f-ff0bc34df4e5@suse.cz/

@geert @kernellogger @monsieuricon Very secretive:
" Name: On behalf of msgid.link OWNER
Organization: c/o whoisproxy.com "

@geert @monsieuricon @kernellogger
https://b4.docs.kernel.org/en/latest/config.html
> can also use https://msgid.link/%s, which is an alias for lore.kernel.org.
So I would guess that should be same owner as for kernel.org. Otherwise b4 docs should not recommend it.

@monsieuricon @geert @kernellogger So basically:

git config --global b4.linkmask 'https://patch.msgid.link/%s'

@gregkh Maybe such reports should be made public afterwards to serve as a warning?

The European Commission has issued a survey on the Governance and Sustainability of Critical Open Source Software.

The survey hopes to identify "pathways for collective efforts" and make "actionable recommendations for public administrations".

It's a relatively short survey, takes max 15 minutes & provides lots of opportunities to rate FOSS as 'very important' 😛

https://ec.europa.eu/eusurvey/runner/FOSSEPS_Governance_and_Sustainability_Survey

#FOSS #governance #NGI #NGI0

@kernellogger @geert That 6.17-rc5 was third complain ~last two weeks about Link tag, so I dropped it from my scripts. I see the rationale that automatically added Link which points to latest patch version, not even to the one with some sort of review happening, is just convenience instead of copy-paste of subject to lore.kernel.org. Useful to me but not worth dying for and I actually understand preference of having really useful Link or no Link at all.