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

@vincent @Conan_Kudo @monsieuricon @jacksonchen666 @marcan it's not true that everyone hates email, nor is it true that good processes can't be used with email. Nevertheless, each project can make its own decisions about how it wants to be run. I would just encourage them to consider platforms like Codeberg before GitHub.

@drewdevault @vincent @Conan_Kudo @monsieuricon @jacksonchen666 @marcan

Purists platforms like Codeberg dont work in practice.

@johannbg @vincent @Conan_Kudo @monsieuricon @jacksonchen666 @marcan [citation needed]

@drewdevault @vincent @Conan_Kudo @monsieuricon @jacksonchen666 @marcan

There is no citation needed since it's a no brainer more often than not companies are doing in house development alongside their F/OSS contributions on the same platform.
Purists platforms dont support such requirements...

@johannbg @vincent @Conan_Kudo @monsieuricon @jacksonchen666 @marcan bad takes hour on mastodon

@johannbg @drewdevault @vincent @Conan_Kudo @monsieuricon @jacksonchen666 @marcan Well software companies ought to host it themselves, specially if they do proprietary software (as after all they likely can't license the code to hosted platforms if it's non-libre).

@lanodan @Conan_Kudo @drewdevault @jacksonchen666 @monsieuricon @vincent @marcan
It's up to the companies themselves to decide whether they should self host or use some cloud based solution for their development workflow + you can do in-house corporate development through paid offerings on any of the major git forges so I dont follow what license issues you are implying corporate are encountering there.

@johannbg @Conan_Kudo @drewdevault @jacksonchen666 @monsieuricon @vincent @marcan https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#3-ownership-of-content-right-to-post-and-license-grants

@lanodan @Conan_Kudo @drewdevault @jacksonchen666 @monsieuricon @vincent @marcan
You need to look at the enterprise section of those git forges.
That said one of the bigger issues the kernel community is faced with ( beside modernizing the development workflow to attract new contributors ) is to unify it as well since currently it's being littered like trash all over the internet, rerouting contributors all over the place which would be resolved if migrated to a gitforge like github.

@johannbg @lanodan @drewdevault @jacksonchen666 @monsieuricon @vincent @marcan The Linux kernel project has enough gravitas of its own that any hosted forge it uses will do well enough anyway. It doesn't *need* GitHub.com or GitLab.com. It just *needs* the forge workflow because that's what developers expect now.

@Conan_Kudo @lanodan @drewdevault @jacksonchen666 @monsieuricon @vincent @marcan
If the Linux kernel project has enough gravitas of its own it would not struggle for participation as many of it's maintainers have complained about and what developers expect now is having a single point of entry for both work and "play" and being able to do partially ( and some developers entirely ) development from their mobile device.

@johannbg @lanodan @drewdevault @jacksonchen666 @monsieuricon @vincent @marcan They're struggling because of workflow and personality problems, both of which are solvable without moving to GitHub.com or GitLab.com.

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