[black3r]

the problem with mail-based patch management is that it doesn't scale well, management wise... when you have hundreds of patches and multiple reviewers who can review them, Github/Gitlab environments make it easier to prioritize the patches, assign who will do the review, filter the patches based on tags, and keep track of what wasn't reviewed yet...,

mail-based patch management is fine for smaller projects, but Linux kernel is too big by now.. it sure is amazing how they seem to make it work despite their scale, but it's kinda obvious by now, that some patches can go unnoticed, unprioritized, unassigned, ...

and open source is all about getting as many developers as possible to contribute to the development. if I contribute something and wait months to get it reviewed, it will deter me from contributing anything more, and I don't care what's the reason behind it. the same goes for if I contribute something and receive an argument between two or more reviewers whether it's the right direction or not and there's no argumentative answer from a supervisor of the project and this situation goes on for months...

[seba_dos1]

> and open source is all about getting as many developers as possible to contribute to the development

[citation needed]

It's what "open source" enables, but it may not necessarily be a desired goal of a FLOSS project.

[xorcist]

Email is just the protocol. What you're really saying is that http-based protocols make more powerful tools possible.

It's not really enough to state your case. You have to do the work.

On the surface, the kernel developers are productive enough. Feel free to do shadow work for a maintainer and keep your patch stack in Gitlab. It it can be shown the be more effective, lots of maintainers are going to be interested. It's not like they all work the same way!

They just have a least common denominator which is store-and-forward patch transport in standard git email format.