We are doing our utmost to strengthen Ukraine's hand.

We've disbursed the fourth €1 billion tranche of our exceptional Macro-Financial Assistance loans.

This funding supports urgent military needs and will be repaid using proceeds from immobilised Russian state assets in the EU.

With this, the EU strengthens its role as Ukraine’s top donor since the full-scale invasion.

Our support to Ukraine is unwavering. We stay ready to respond swiftly to any further requests.

→ https://europa.eu/!P6YwqY

@ljs My post was of course simplifying or generalizing, because no one will take freshmen for example into maintaining MM or scheduling. What I wanted to say there are many non-complicated driver subsystems which need new maintainers and it is relatively easy to start there. If you have patches already in the kernel and the community recognizes you (vide xz case), then just start reviewing and in no time you will be there.

Assuming of course one knows Git, because that's another problem with young folks these days - they know Github but do not understand Git...

I think many kernel developers - including myself, a long time ago - believe that becoming a Linux kernel maintainer is a difficult process. As if some secret group has to choose you, you need to prove yourself, and then a Masonic lodge will select the best candidates from a huge pool of competition.

That's simply not true. Becoming a Linux kernel maintainer is actually quite easy.

The difficulty lies in staying one.

Every now and then, I notice subsystems that need more maintainers. Do you want to be one?

Of course taking maintainership position and being a true maintainer are a bit different things, but I hope you get the point...

@monsieuricon There was a guy who once called Linux communism, so obviously not that far away. What was the guy's job? Some big American company, right?

Today's misinformation provided by Google Search's "AI Overview" (which cannot be disabled, apparently):
"All EU member states are parties to the Rome Statute, except for Turkey."

(I am not complaining that the AI missed today's withdrawal of Hungary)

@Conan_Kudo @geert Plus, your tags given to cover letters suggest - following your logic - that you only reviewed cover letter and you did not read the patches at all.

@Conan_Kudo Well, your opinion here is contradictory to Linux kernel process. It's clear here:

> By offering my Reviewed-by: tag, I state that:
> (a) I have carried out a technical review of this patch to
> evaluate its appropriateness and readiness for inclusion into
> the mainline kernel.

Nowhere, nowhere in the Linux kernel process is any mention that the tag placement matters and suggesting that it does not only contradicts practice of all reviewers and maintainers but it makes no sense. It just creates noise and additional effort on receivers of your email.

@Conan_Kudo @geert Review under commit msg is the review of everything. Don't ask people to scroll through hundreds of lines just to figure out that they do not need to even scroll! (because b4 will collect the tag, but they had to be sure not to miss any feedback).

As I said, this is is disrespectful to me, this is wasting my time. The way to recover my time is to just ignore such emails.

2024 was a record-breaking year for forest fires in Ukraine.

This is another devastating consequence of Russia’s illegal invasion.

Nearly one million hectares were burnt in the country – more than twice the area burned in the EU in the same period.

The EU is committed to helping Ukrainians strengthen their rescue and fire services by providing them with machinery and protective equipment.

With Ukraine – and its brave firefighters – unflinchingly.

ℹ️ https://europa.eu/!fxW7MD

#EU

Therefore special thanks for Geert and Rob who did trim their replies - they end with Reviewed-by tag. :)

I sent a simple, yet not the shortest, DT bindings patch for the Linux kernel. I got five review tags in response, for which I thank you, however three (60%) of them where in format:

> My commit msg...
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Reviewed-by: Mr. Foo

> here goes
> my ...
> entire patch
> for su knows how long.
> Really long!

I was complaining about this on the lists already. I am not going to, heh, no one should be to, scroll through entire message to check whether there was something after that Reviewed-by tag. Or after comment.

Knowing that it is trivial to remove unneeded context (see below), I find that just disrespectful to me and my time.

I am going to ignore EVERYTHING from something which looks like end of message. if you put there something, your problem.

E.g. if one uses mutt and vim - that's part of your alias:
```
nmap <silent> <leader>A :.,$d<CR>A<CR><CR>Acked-by: Krzysztof Kozlowski <krzk@kernel.org><CR><CR>Best regards,<CR>Krzysztof<CR><ESC>
```

@cas Yup, that's another patch coming from some tools or coccinelle without even understanding the code.

And at least two patches are so obviously wrong and so obviously not compiled, that it is actually reassuring. Why? Because it cannot be a try of sneaking faulty patches into the kernel (see UMN.edu and their hypocrite commits). It's just to plain junk code, too obvious for real attack:

https://lore.kernel.org/all/20250313160959132rMOoPpNjSNTlB-E6rMOuj@zte.com.cn/
https://lore.kernel.org/all/20250313144430115dzzemB3yO4jZvI29ZZebY@zte.com.cn/

Although, exhaustion of resources is also sort of an attack...

Here's the flood: https://lore.kernel.org/all/?q=f%3Azte.com.cn

ZTE or zte.com.cn apparently decided to flood kernel with extremely poor quality, automated patches. Reminds me previous flood from Vivo.com. Some of the patches were never built and clearly do not compile. Some are looking correct, but are wrong if you open the context of the file (e.g. using sysfs_emit in procfs or some other code). None of the review feedbacks were responded to, they just keep sending the code, sometimes 5 same patches without noticeable changes or without changelog.

And I bet somewhere within this flood of automation-generated stuff, is actual fix or actual bug pretending to be a fix but introducing a vulnerability.

When Trump says that he can apply economic pressure on Putin, he's lying. He has very few levers that haven't already been pushed. Using his own analogy, Trump acts like he has an ace up his sleeve, but he only has a pair of jokers. The only sure way to apply pressure on Putin is to give Ukraine all they need to win on the battlefield.

If #Ukraine really did attack #Twitter, | think the only logical thing is for #Elon to sign a cease fire immediately, give them half of Twitter and make sure he says thank you.

Good morning to readers; #Kyiv remains in Ukrainian hands.

#Ukraine helped the U.S. in its invasion of Iraq, losing 18 of its own men.

But when #Kyiv needed help, the U.S. leveraged Ukraine's weakness.

Serhii, who served in Iraq, knows the risks of allying with the U.S.

PSA: please don't use git.kernel.org directly for your CI needs. It is not viable for us to provide enough capacity to withstand dozens of CI nodes all trying to clone linux.git at the same time for multiple CI farms. You *will* get ip-blocked. Please set up a local mirror and hit that instead.