[zer00eyz]

I think you have a story eyed view of github... You might want to go read Linus own thoughts on the matter in the linux GitHub backup repo

Git is a tool built for a project of the kernels scope, scale and organization.

Github is a thin web interface over top of that, it cuts some corners here and there and gets opinionated about how you should manage code (pull requests).

Think of it this way: most git hub projects end up with a monotonic output... the kernel isnt that. Between the current version someone is using, the next version that is being developed and the older versions getting back ports there's a lot going on there. Much more than GitHub and a pull request would cover.

[jorvi]

Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution. People see a bit of code they want to improve, they improve it, and then instead of just opening a PR (and perhaps iterating on it), now they have to learn a weird ancient e-mail workflow and will probably get chewed out for messing it up.

No one is saying to take away mail-in patches but it is positively archaic.

[zer00eyz]

>> Likewise, I think you have a starry-eyed view on how much friction it creates which equals less contribution.

Is it friction? Or is it a filter?

You might remember being a kid and there was the sign in front of the ride that said "you must be at least this high to ride".... The kernel dev process isnt for casuals. It's designed that way.

There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests.

You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons).... Your going to look at git in a very different way and many of githubs features are gonna feel on par with linkedin adding twitch style videos and zoom adding mail features...

[jorvi]

> Is it friction? Or is it a filter?

Friction.

> There's a lot of folks out there who have popular projects on GitHub who are over the endless stream of BS from AI generated pull requests.

So be stringent. First below-par PR get some guidance, pointers and perhaps a reprimand. Second time, a warning, third time a ban.

> You should really dig in deep to what goes on with the kernel, the work flow, why it is that way and why GitHub is outright incapable of supporting kernel dev (there are reasons)....

Code is code. If someone has an improvement, they can offer their new code.

I’m sure the kernel has a unique workflow, but it ultimately boils down to that, no?