Konstantin Ryabitsev on Email, b4 and the AI Patch Flood

On the first afternoon of Open Source Summit Europe 2026 in Prague, I recorded a Udienza interview with Konstantin Ryabitsev, who has looked after kernel.org infrastructure at the Linux Foundation since 2011 and wrote b4, the tool most kernel maintainers now use to handle patches.

I asked him to explain the kernel’s email workflow. “Which part do you want to know first?” he asked. “Everything,” I said. He delivered: the conversation ran to eighteen minutes. Here are the highlights. Quotes are from our recording, lightly edited for clarity.

Why the kernel still runs on email

Outsiders often ask why Linux does not “just move to GitHub”. Konstantin’s answer starts with history and ends with resilience.

Many maintainers have efficient, long-established workflows, and they value that development is decentralised and not controlled by any one company:

“GitHub is a commercial company and a proprietary platform. Even though it is Git, after you do the push, everything below that is proprietary. It is very friendly to developers right now. Who knows, maybe years later.”

He reminded me why Git exists at all. In the early 2000s the kernel used BitKeeper, a proprietary, centrally hosted tool with good ideas. When BitKeeper changed how it allowed access, everybody agreed the kernel was locked into one proprietary company. Linus Torvalds went away for a couple of weekends and came back with Git.

The second reason is resilience. When kernel.org was compromised in 2011, before Konstantin’s time, the infrastructure was down for weeks. Kernel development carried on regardless:

“Kernel development did not depend on kernel.org being up, and we would like to keep it that way. We assume kernel.org can be brought down by an adversary, by somebody doing stupid things, or by AI crawlers descending and consuming all the bandwidth they can. So we want to keep Linux development not tied to any central infrastructure: decentralised, distributed, point-to-point.”

And, as he put it, email is still the only platform that gives them that. Replacing it would need a “flag day”, where everybody stops using email at once, which is very hard with a user base this large.

The scale: about a thousand patches a day

On the main Linux kernel mailing list alone, he estimated about a thousand patches a day, depending on whether it is a merge window. There are many more specialised lists on top of that.

b4: improving the workflow without forcing anyone

b4 started as a way for maintainers to grab a patch series from the mailing list and prepare it to apply to their Git tree. It grew into a tool for contributors to prepare and send series in exactly the format maintainers like to see. What he is working on now is review: quick replies, optional agent integration, and tracking multiple series and revisions at once.

The design principle is the part I would copy into any platform team:

“Greg Kroah-Hartman has a very efficient, established workflow. I don’t want to tell him: stop doing this, start doing that. Anybody who is already happy can continue the way they’re doing things. Anybody who is just now becoming a maintainer or a reviewer, I can offer them: this is already efficient, try this.”

How do you know who sent a patch?

I asked how they verify that a patch comes from the person it claims to come from. His answer was honest:

“We don’t really. Distributed trust is always complicated. A lot of it is: it’s the same person sending patches for the past five years, and they’ve always used the same key, so you build up trust that way. It’s not a solved problem.”

There is tooling for it. Konstantin’s patatt adds a cryptographic signature to patch emails, similar to DKIM, so that a patch can be verified end to end regardless of which mail servers and archives it passed through. At the top of the tree the process is well established: when a maintainer sends a pull request to Linus, it has to be signed with their PGP key, and Konstantin maintains a keyring of about 600 keys of major maintainers so that Linus can verify it.

Keeping lore.kernel.org from becoming a single point of failure

lore.kernel.org aggregates all the mailing lists and patches and is very searchable, but it is a central platform. So Konstantin is working on making it easy for people to keep local, continuously updated copies, say of the last three months, and on failover options, possibly including a Tor hidden service that maintainers know about, so that work continues even if someone knocks the main site out. Again, without changing anybody’s existing workflow.

Should young people still go into tech?

I asked the question I hear constantly: with AI getting better, should young people still choose tech? He did not pretend to know:

“We don’t know how it’s going to play out. We’re just guessing. The whole AI system is heavily in debt and heavily subsidised, so something that is cheap and easy today doesn’t mean it’s going to be cheap and easy tomorrow. So don’t abandon your tech skills. Keep hacking if it’s fun. A lot of people got into tech because hacking is fun.”

And on working with AI-generated code:

“Sometimes I really hate the code, sometimes the code is good. It’s like working with contractors or interns. Sometimes you have a brilliant intern who creates great code, and sometimes the same person creates code that isn’t good, and you tell them how to fix it. You still need to be able to figure out whether it’s good code. I wouldn’t take stuff from an agent without review and stick it into production, because the agent doesn’t care. It has no problem creating code that’s just junk.”

The AI patch flood and maintainer burnout

The most important part of the interview was about what AI-generated contributions do to maintainers. It was on the agenda for the Maintainers Summit the next day. Konstantin described two problems.

First, motivation. Some people submit patches because “Linux kernel contributor” looks good on a CV:

“A lot of it is a humongous patch across five or ten different subsystems, and the person who wrote it is not going to be there when the problems come up. It’s a one-off: they wrote it, and they moved on.”

Second, quality that looks fine on the surface:

“It’s well formatted, it looks good, but it breaks a bunch of stuff, because the person who wrote it did not run any checks, any CI, any of the unit tests. The maintainers now have to look through it, figure out that it’s junk, and send their NAK back. This just wasted 30 minutes of multiple people’s time, and it does not scale. Maintainers are the hardest part to scale.”

He named the mechanism behind burnout: decision fatigue.

“They have to continuously make decisions: is this good code, should I take this in? When you have to make really critical decisions multiple times a day, day after day, month after month, it burns you out.”

What the kernel wants instead are contributors who care about the code and stay around, so that when something they wrote breaks, someone can ask them why. The difficulty is telling the two apart:

“We obviously don’t want to discourage people. A new contributor whose code is AI-generated, but who clearly reviewed it and is happy to work with the maintainers, we want those people to stay. But how do we tell them apart from people who are only there because it’s now easy to submit patches? We don’t have a solution to this yet.”

Some projects have reacted by banning AI-generated patches outright, “not because they are against AI, but because it is not scalable for them to review all the incoming patches”. Konstantin does not want the kernel to go that way:

“I think there is a good middle ground we can find. We’re just not there yet.”

Takeaways for any project

1. Design tools that improve the workflow without forcing it. b4 succeeded because nobody had to change.
2. Plan for your central infrastructure to disappear, whether through an attack, a mistake or AI crawlers.
3. Protect reviewers, not just contributors. Decision fatigue is the real scaling limit. Require contributors to run the checks before a human has to look.
4. Review AI-generated code like an intern’s. Sometimes brilliant, sometimes junk, and never shipped without review.

If you have an idea for a tool that should exist, or want to contribute to existing ones, Konstantin pointed to the kernel tools mailing list. Thank you, Konstantin. The full episode will be on udienza.com.

More from Open Source Summit Europe 2026

• Greg Kroah-Hartman on AI Bug Finders, the CRA and Linux at 35
• Kernel Maintainers in Prague: Greg KH and Arnaldo Melo
• Open Source Summit Europe 2026: Complete Prague Guide