Hi, > If some debian developer wants to make it to be their special mission > to help out new contributors, and be that ombudsperson to review > patches, and tell them how "no really, you need to follow the > upstream's documented requirements for code submissions[4]", or "gee, > it appears that your code doesn't even build; I suggest you try to > test-compile your patch and run it through the project's regtression > suite", or, "Ah, your patch seems to allow shell scripts from the > network to be blindly run on the target system", great!
We have CI that does most of this, and I believe strongly that investing X amount of effort in the CI will have great ROI in doing the above mostly automatically for all submissions, so that once a human starts looking at a new submission the contribution should already be past a certain bar. > This is why careful review of patches is super important, and why I am > personally very dubious of the Forge Pull Request model. Unless > people are super, super careful about code review, a "git pull" could > very easily pull in some malicious code. Maintainers need to be super > paranoid, especially for code contributions coming from an unknown new > contributor. After a `git fetch` or a `git pull` it is very easy to review what the change is or diff it against the current main branch. There are a bunch of tolls, including of course the usual gitk and `git difftool --dir-diff` + Meld. I don't think the Forge model makes git usabiilty issues any worse, on the contrary it gives an additional place where people can browse the commits visually and drill into discussions about each changed etc. > Just for myself, I find that e-mail review is just more effective; I > can review patches much more easily when I am partially off-line, such > as while on an airplane, or on a cruise ship. It's much more > difficult to do this via a web-based Forge system. Indeed, Forge's don't work offline, but you could git pull/fetch the branch before you board an airplane? And then after review git merge locally? And once you are off the flight run git push and all modern Forges will automatically detect that the commit landed on main and close all related pull requests and issues. I know a lot of veterans in the industry have very good e-mail setups and are very efficient in reviewing patches by e-mail. I am not asking you to abandon it. You should do what you want. But I am worried about the next generation of open source contributors. I have never seen anyone under 40 e.g. use Emacs to read email. If you only focus on your own "local optimum" and don't think about the more generic working methods and document them and teach them to new contributors, somebody else will teach them something, and if those "others" are developer advocates from Microsoft, then open source won't win the long game.. Personally I like to support things like e.g. GitLab and Pulsar because I see it as the most viable competitors to GitHub and VS Code. As a lot of people have experienced doing reviews with the support of nice UIs, CI that run on every commit etc, I don't think devs will en mass go back to using just e-mail for code reviews.
