@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

The only reason 3. is the hardest is because the process is hilariously broken. The overhead is ridiculous, and that drags out the process, which increases the chances of conflicts and collisions, further dragging out the process. And then there's the human element of frustration over all this crap, which again... further drags out the process.

There is absolutely no reason why it should be harder to upstream support for a proprietary undocumented bespoke platform than it was to reverse engineer it all and write the code in the first place. That's just ridiculous. If the process for getting code from point A to point B eclipses the development process itself, that is an utterly broken process.

@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 Do you want to jump in and make the case for your service, @drewdevault ?

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