@jacksonchen666 @marcan His intention is pretty clear: he doesn't want to do email-based patch review anymore. It sucks and everyone hates it.
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.
(I'm not trying to be contrary, this is literally my worry.)
@monsieuricon @marcan @Conan_Kudo @jacksonchen666 have you looked into https://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.
@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.
@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 @monsieuricon @jacksonchen666 @marcan Do you want to jump in and make the case for your service, @drewdevault ?
@drewdevault @vincent @Conan_Kudo @monsieuricon @jacksonchen666 @marcan
Purists platforms like Codeberg dont work in practice.
@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
@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.
@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 @lanodan @drewdevault @jacksonchen666 @monsieuricon @vincent @marcan
I dont think much would be resolved if it does not move to a gitforge instance and arguably it's more of a generation problem than a personality problems.
"Hard times create strong men, strong men create good times, good times create weak men, and weak men create hard times."
With the snowflake generation which does not know head or tails what they are or want out of life we are simply at the end of that cycle.
@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.