@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*.

@Conan_Kudo @jacksonchen666 @vincent @marcan no it isn't. If you knock out kernel.org, developers can still collaborate using the same process (email review) and put out a release that can be verified for authenticity by its digital signature.

@Conan_Kudo @jacksonchen666 @vincent @marcan kernel.org was offline for months in 2011 and Linux releases kept going out.

@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.

@Conan_Kudo @jacksonchen666 @vincent @marcan I'm not convinced this is accurate. It's easy to blame tooling, which is the most visible part of the process. However, I'm pretty sure if we replace this with the most amazing workflow of submitting and reviewing the code, we'll still be 90% in the same situation, because:

1. Writing kernel code is hard
2. Reviewing kernel code is even harder
3. Upstreaming to rapidly-moving mainline is the hardest

We need maintainers, preferably well-paid teams of maintainers, much more than we need a shiny code review toolset.

@monsieuricon @Conan_Kudo @jacksonchen666 @vincent @marcan

Moving a project ( be it the kernel or something else ) to a gitforge like Github where the largest developer base on the planet resides will increase the likelihood of people ( or companies ) participate in that project while using archaic means of development workflows ( as effective as they might be ) will not.
It's somewhat hard for project to complain about lack of participation if the project is not located where everyone are.

@Conan_Kudo @monsieuricon @jacksonchen666 @marcan@treehouse.systems Do you want to jump in and make the case for your service, @drewdevault@fosstodon.org ?

@Conan_Kudo @vincent @marcan @jacksonchen666 SMTP is not the only channel for passing around RFC2822 messages, though. However, it remains the only widely used distributed protocol for doing so.

@Conan_Kudo @vincent @monsieuricon @marcan @jacksonchen666 Sourcehut allows submitting patches using the web UI.