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