@jacksonchen666 @marcan His intention is pretty clear: he doesn't want to do email-based patch review anymore. It sucks and everyone hates it.

@Conan_Kudo @jacksonchen666  

This. ☝️

There are plenty of kernel maintainers/submitters tired of the terrible patch model and looking for an alternative. We have two drivers in that tree, it's a great small-scale test. And I like pushing boundaries because that's the only way we get progress.

@marcan @Conan_Kudo @jacksonchen666 how do we manage to both provide a better workflow *and* avoid lock-in into an open-core tool like gitlab?

(I'm not trying to be contrary, this is literally my worry.)

@monsieuricon @marcan @Conan_Kudo @jacksonchen666 have you looked into sourcehut.org/ ? You can probably get the best combination of web, email and CI integrated together, while being 100% open

@vincent @monsieuricon @marcan @jacksonchen666 Sourcehut is flawed in that it considers email review processes *good*. Fundamentally, they're not.

And they're a pain if your employer uses an email system that's unfriendly to this model, like Microsoft 365 or on-premises Microsoft Exchange.

@Conan_Kudo @vincent @marcan @jacksonchen666 a single point of failure platform is also not really acceptable. Imagine that you're sitting on a zero-day exploit of the Linux kernel and you want to prevent a fix from going out. Knocking out the central code management system is the logical move.

@monsieuricon @jacksonchen666 @vincent @marcan

That's not a useful argument because knocking out kernel.org is enough to take out most of the review+release processes *now*.

@monsieuricon @jacksonchen666 @vincent @marcan But then those reviews are not archived, right? What stops you from using those fallback processes when a forge is down instead? Your fallback processes don't have to be stellar, they just have to work. Email based review can work in a pinch, but it shouldn't be the default anymore.

@Conan_Kudo @jacksonchen666 @vincent @marcan if the solution is to fall back to what we're doing now, then we've not really solved anything, just complicated the process and made it more fragile.

@monsieuricon @jacksonchen666 @vincent @marcan And you know what today's kernel development process leads to? Impossible to follow code review, inability to leverage contemporary CI/CD systems, and a sprawl of patch sets that nobody can find, track, or push at. It also means that the flow of enthusiast Linux kernel contributors continues to die out as the process becomes further and further disconnected from general expectations of OSS development.

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml