Emailed patches are not a huge deal for you after submission, and theoretically the first submission should be the same for both (apart from the tool you use to

Emailed patches are not a huge deal for you after submission, and theoretically the first submission should be the same for both (apart from the tool you use to make it). Maintainers reply to emails with comments and you reply to them. The maintainers need to have or setup some specialized tooling to replace GitHub's CI and automation, but you don't care about that[1]. The main difference is that GitHub projects often do squash-on-merge, therefore you add fixes on top and also the commit messages don't mean much. Linux instead keeps the individual pieces so they want you to pay huge attention to the individual commit messages, the buildability and functionality at each step, and squashing each fix in the right patch. This means that reacting to the reviews, and sending subsequent versions of the changeset, is actually harder than sending the first submission! The reason however is unrelated to the use of an email workflow. [1] For the specific case of Linux, testing is way out of scope of GitHub/Gitlab's CI; for other projects using email workflow, you can usually push to a branch to have CI run and only submit when it's green.