K. Ryabitsev 🍁
@monsieuricon
Moderator
Posts
1888Following
223Followers
2372This account is for Linux/Kernel/FOSS topics in general: #linux, #kernel, #foss, #git, #sysadmin, #infrastructure.
For my personal account, please follow @monsieuricon@castoranxieux.ca.
Montréal, Québec, Canada 🇨🇦🇺🇦
K. Ryabitsev 🍁
monsieuricon
@corbet To highlight the main point I'm trying to make, the problem isn't that linux-kernel receives a lot of mail. It's that it has 3,000 subscribers, which translates into about 3 million individual messages daily on average. This is high enough volume that many email providers start throttling us back.
0
3
4
K. Ryabitsev 🍁
monsieuricon
@kernellogger @corbet Yes, if you use get_maintainer.pl (which is how you're supposed to do it), linux-kernel will *always* be included.
1
0
1
K. Ryabitsev 🍁
monsieuricon
@arstechnica "As for the EV element, it was something of a relief to see that the electrification of the vehicles didn't seem to make a difference in the safety of the accident. But even though the high-voltage system automatically disconnected, I'm sure Mercedes-Benz will forgive me if I'm hesitant to approach a wrecked EV."
Translation: "I was shown all evidence that EVs are no more dangerous than ICE vehicles, but writing that would generate fewer clicks, so I will throw in some words about my irrelevant monkeybrain feels."
Disappointing to see Ars doing this, but I guess this is what we get for relying on ad-driven media.
Translation: "I was shown all evidence that EVs are no more dangerous than ICE vehicles, but writing that would generate fewer clicks, so I will throw in some words about my irrelevant monkeybrain feels."
Disappointing to see Ars doing this, but I guess this is what we get for relying on ad-driven media.
0
1
6
K. Ryabitsev 🍁
monsieuricon
RFC: switching "THE REST" in MAINTAINERS away from linux-kernel@vger.kernel.org
In which I brazenly suggest that we should stop sending all patches to the LKML and send them to a different list with moderated subscription.
https://lore.kernel.org/ksummit/20231106-venomous-raccoon-of-wealth-acc57c@nitro/
In which I brazenly suggest that we should stop sending all patches to the LKML and send them to a different list with moderated subscription.
https://lore.kernel.org/ksummit/20231106-venomous-raccoon-of-wealth-acc57c@nitro/
2
4
16
K. Ryabitsev 🍁
monsieuricon
@mupuf @ljs @liskin my usual concern with running a forge is that suddenly there's a single target that someone can attack and stop all kernel development. Imagine you have a 0-day that lets you own billions of devices worldwide. Just knocking out forge.kernel.org prevent it from being fixed. Yes, we can fall back to coordinating everything via mail when this happens, but that means we haven't really fixed the underlying problem.
2
0
4
K. Ryabitsev 🍁
monsieuricon
@liskin @mupuf @ljs b4 will try to guess where the series belongs. And if the series was sent with b4 itself, it would also have a base-commit, which will tell you exactly where in the tree that belongs, too.
Also, if you try b4, you won't really have to configure your email server, as we also support submitting a patch series via a relay service.
There's still lots of work left to do, but we *are* listening.
Also, if you try b4, you won't really have to configure your email server, as we also support submitting a patch series via a relay service.
There's still lots of work left to do, but we *are* listening.
0
0
3
K. Ryabitsev 🍁
monsieuricon
Edited 1 year ago
According to my back-of-napkin calculations (looking at the number of archived messages in the past month, averaging it per day, and multiplying by number of subscribers):
- vger.kernel.org delivers about 4.5 million messages per day
- 70% of that is linux-kernel@vger, with about 3.2 million messages delivered per day
- a very remote second is netdev@vger (300,000 messages delivered per day)
- even a more remote third is kvm@vger (133,000 messages delivered per day)
Current migration stats:
Out of the total of 203 public vger lists:
- 48 lists will be sunset (due to obsolescence/inactivity)
- 40 lists are already migrated to new infra
- 115 still reside on legacy infra
The 40 migrated lists are about 788,000 messages daily, or ~20% of all traffic, so 80% of all mail traffic is still going through the legacy infra.
I hope to complete all migrations by this holiday season.
- vger.kernel.org delivers about 4.5 million messages per day
- 70% of that is linux-kernel@vger, with about 3.2 million messages delivered per day
- a very remote second is netdev@vger (300,000 messages delivered per day)
- even a more remote third is kvm@vger (133,000 messages delivered per day)
Current migration stats:
Out of the total of 203 public vger lists:
- 48 lists will be sunset (due to obsolescence/inactivity)
- 40 lists are already migrated to new infra
- 115 still reside on legacy infra
The 40 migrated lists are about 788,000 messages daily, or ~20% of all traffic, so 80% of all mail traffic is still going through the legacy infra.
I hope to complete all migrations by this holiday season.
1
5
17
K. Ryabitsev 🍁
monsieuricon
@est oooh, I gotcha! No worries, it definitely helps to have the right context. :)
0
0
0
K. Ryabitsev 🍁
monsieuricon
@est shouldn't be, it's fully compatible with everything you'd send with git-format-patch. If you do think it's incompatible, then I'd love to hear in what ways.
1
0
1
K. Ryabitsev 🍁
monsieuricon
@est wait, care to try this instead of git-format-patch? https://b4.docs.kernel.org/en/latest/contributor/overview.html
1
0
1
K. Ryabitsev 🍁
monsieuricon
So many truths are hidden,
So many facts untold,
Queries left unbidden,
Concealed below the fold.
My head droops to the table,
But I must remain informed:
"Is the kernel stable?"
"How is babby formed?"
So many facts untold,
Queries left unbidden,
Concealed below the fold.
My head droops to the table,
But I must remain informed:
"Is the kernel stable?"
"How is babby formed?"
0
32
62
K. Ryabitsev 🍁
repeated
repeated
Worf Email
WorfEmail@botsin.spaceGeordi,
No one has been receiving my emails for many months. This is a significant security risk and it must be fixed.
Worf
0
1
0
K. Ryabitsev 🍁
monsieuricon
@b0rk I think there are harmful and non-harmful ways of using "rebase." When preparing your set of patches for submission upstream, rebase is essential -- you can split large patches into logically smaller ones, fix typos, reorder commits for better clarity and squash some of them together if they really don't need to be two separate actions. All of this is easily accomplished with "git rebase -i". It is also useful to be able to rebase your work on the newer version of the main branch right before you submit your changes upstream.
However, many other applications of rebase can be sloppy and harmful, especially when used without proper understanding of the effects it will have on the project history. I many situations, merge commits are preferable to rebases.
However, many other applications of rebase can be sloppy and harmful, especially when used without proper understanding of the effects it will have on the project history. I many situations, merge commits are preferable to rebases.
2
3
6
K. Ryabitsev 🍁
repeated
repeated
Julia Evans
b0rk@jvns.caconfusing git terminology https://jvns.ca/blog/2023/11/01/confusing-git-terminology/
12
6
1
K. Ryabitsev 🍁
monsieuricon
@davidrevoy Since you're a Fedora user, the most proper way to do this is to report a bug to the Fedora bug tracker. The Fedora kernel maintainers will then work with the upstream kernel to get this solved. This way you don't need to worry about Protonmail problems *and* you will follow the correct procedure.
1
0
4
K. Ryabitsev 🍁
monsieuricon
@davidrevoy I'm sorry you didn't have a great experience -- fwiw, I'm working on making it easy to report bugs via bugzilla.kernel.org and actually have that be effective.
1
0
5
K. Ryabitsev 🍁
monsieuricon
@protonmail @davidrevoy @kkarhan Having a WKD doesn't imply we want to receive PGP encrypted mail -- its primary purpose is to make it easy to retrieve keys for signature verification on git commits and packaged releases. If you can turn this off for kernel.org addresses, then please do so.
2
1
3