Why large OSS projects still use email patches

Meta
1

In our recent discussion with Thomas Petazzoni, Thomas mentioned the debate about using older collaboration methods such as emailing patches vs newer methods like Github pull requests (PRs). The following article is an excellent discussion of these trade-offs.

https://drewdevault.com/2020/09/02/Linux-development-is-profoundly-distributed.html

Doing an analysis on the MAINTAINERS file in the Linux source tree, I get 3045 unique maintainers:

[cbrake@mars linux]$ grep '^M' MAINTAINERS | uniq |  wc -l
3045

The Github mirror shows 11,071 contributors.

Does the Github/PR model work for large open source projects? The Kubernetes projects has 2,893 contributors, 849 open pull requests, and 2,031 open issues. The Kubernetes project is roughly an order of magnitude smaller than the Linux kernel in terms of the number of contributors, and even then it does not seem to be keeping up with issues and PRs. I do like the PR workflow, but it appears that workflow probably only works for small/mid size projects. Github does provide a feature in their pull requests to compare across forks:

image
image982×107 9.57 KB

However, that appears to only go one level deep – for a Linux size project, it seems you would need to be able to nest forks many levels.

Gitlab looks similar in that you can target a pull request at any of a repos forks, but not sure if that extends to forks of forks.

image
image1323×321 28.8 KB

Maybe there is an opportunity for a distributed pull request mechanism? Looks like someone already thought of this:

2

very good points. I have thought about it a bit and I do like fork and pull model and I think one issue with per pull request CI is usually resources to run builds and tests and having maintainers pick and aggregate patches means these patches can be tested in bunches. It helps in good use of infra. So I think per commit CI becomes expensive very quickly as the project becomes complex and contributions grow. So yes distributed code review system works perhaps giving control to maintainers to merge branches into a ‘staging’ branch before firing builds etc.

I do not buy any other arguments on email based workflows besides what I said above.